Currently, we have a couple templates with local customizations to do
things like pass on Kernel parameters, like this example from the Kickstart default PXELinux template.
<%-# NOTE:
# If host is VMware (If it uses the VMware provider), than pass
kernel params to avoid ‘consistent network device naming’.
# If host is not VMware, then assign a serial console for IPMI/SOL.
Assuming standard Supermicro ttyS1 for now.
-%>
<% if @host.provider == 'VMware' -%>
<%-# I am a Virtual Machine -%>
APPEND initrd=<%= @initrd %> ks=<%= foreman_url('provision')%> network
ks.sendmac net.ifnames=0 biosdevname=0
<% else -%>
<%-# I am a Physical Machine -%>
append initrd=<%= @initrd %> ks=<%= foreman_url('provision')%> network
ks.sendmac console=tty0 console=ttyS0,9600
<% end -%>
<% else -%>
APPEND initrd=<%= @initrd %> ks=<%= foreman_url('provision')%>
ksdevice=bootif network kssendmac
<% end -%>
I noticed that newer versions of the Kickstart default PXELinux template
have added an array named <%= options %> or <%= pxe_kernel_options %>,
like so:
Foreman 1.13:
<% elsif @host.operatingsystem.name == 'Fedora' and @host.
It looks like many of many customizations can be folded into one of these
arrays, which would simplify our own templates and make it easier to keep
them in sync with the upstream versions.
How could I make use of the <%= options %> or <%= pxe_kernel_options %>
arrays? I can't find any documentation about them. Would I want to set
parameters on a Host Group basis?
> It looks like many of many customizations can be folded into one of these
> arrays, which would simplify our own templates and make it easier to keep
> them in sync with the upstream versions.
>
> How could I make use of the <%= options %> or <%= pxe_kernel_options %>
> arrays? I can't find any documentation about them. Would I want to set
> parameters on a Host Group basis?
Options array is defined in the template itself, just scroll up a page.
It was just a refactoring to make the template little bit more readable.
For the pxe_kernel_options, you identified it right, it's an attempt to
move some customization from templates into host parameters. Currently
it only accepts blacklist options for Redhat systems. The method is
defined in Operatingsystem model. For all other systems it returns just
an empty array.
If you can help us defining which options to include, that would be
great. I only use Redhat systems and blacklist is the only parameter I
make use of, so can't think of others.
Maybe we could make a generic param kernel_cmdline that would work with
any OS. If you like the idea, file a feature ticket for me, easy change.
> > It looks like many of many customizations can be folded into one of these
> > arrays, which would simplify our own templates and make it easier to keep
> > them in sync with the upstream versions.
> >
> > How could I make use of the <%= options %> or <%= pxe_kernel_options %>
> > arrays? I can't find any documentation about them. Would I want to set
> > parameters on a Host Group basis?
>
> If you can help us defining which options to include, that would be
> great. I only use Redhat systems and blacklist is the only parameter I
> make use of, so can't think of others.
>
Our own examples are a bit localized, but are probably useful for other
groups. Currently, I'm adding options using simple 'if/elsif/else'
statements in the body of my templates, but I think this could be
accomplished more elegantly.
The first option is to workaround a bug with VMware and Red Hat's
consistent device naming, which creates network device names with crazy
names like 'eno16777723' and 'eno33555201'. Our workaround is to
append 'net.ifnames=0
biosdevname=0' to the kernel parameters, as you can see above.
The second is to activate a serial console for our Supermicro bare metal
servers, using the device assigned for the IPMI/BMC's "Serial over LAN"
feature.
If these kernel parameters are added during provisioning, they persist
after the provisioning is complete. Systemd will automatically activate the
serial console,
and there is no need to add a new Puppet class to make the changes.
Maybe we could make a generic param kernel_cmdline that would work with
> any OS. If you like the idea, file a feature ticket for me, easy change.
Sounds good. I'll file a ticket soon.
(Whoa, sorry for the delay. I thought I sent this message last week!)
-= Stefan
···
On Fri, Oct 14, 2016 at 1:21 AM, Lukas Zapletal wrote:
