You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Changing the default parameters on /etc/grub2.cfg or grubby args is working around the existing tooling built into the OS and grub:
Adding args should be done through templating files into /etc/grub.d for each override (RH Grubby Docs and StackOverflow example), such as /etc/grub.d/60-stackhpc-grubcmdline-quiet then simply invoke grubby or grub-mkconfig without args
Removing entries would still edit /etc/default/grub, but ansible.builtin.lineinfile should do the "surgical cuts" instead to minimise the changes to the file rather than trying generate a "new" cmdline using Jinja templates (which could generate wrong and result in an unbootable machine).
Alternatively, a grub script can be templated out /etc/grub.d which iterates over the GRUB_CMDLINE_LINUX* variables and appends every argument back except the matching one using the for in and if statements built into grub script. This would be more correct, but I don't have an adaptable example to hand.
The biggest advantages are:
Prevents the role fighting upstream changes if they change the default cmdline (e.g. in-place OS upgrades)
Would avoid the problems with the UUID
Makes troubleshooting easy to diagnose if it's a distro or kernel flag change: mv /etc/grub.d/*stackhpc-grubcmdline /etc/grub.d.bak && grubby ...
Idempotent by default, template through ansible then use a handler for re-running grubby and notify reboot if any template / lineinfile has changed
If not the above changes:
I think old_cmdline != kernel_cmdline | select() | sort | list is potentially brittle as there will be more problems like this in the future. Instead it could be something akin to the following pseudo code:
changed_when: not(all(grub_cmdline_linux_new in kernel_cmdline)) or any(grub_cmdline_linux_remove in kernel_cmdline)
This would only check for keywords the user has explicitly set in the role, rather than being affected by parameters (such as root=UUID=abc...) which they have not specified at all. However, this still leaves the potential problems around directly generating /etc/default/grub
The text was updated successfully, but these errors were encountered:
Whilst configuring machines with the
grubcmdline
the check for the command line is not idempotent, so the same machine will reboot every time.I suspect this is either
crashkernel
appearing multiple times in the args (which we should fix in the caller, but should the role does not guard against) orresume=UUID
gets packed into the cmdline multiple timesThe role should either throw a
fatal:
message, or not notify the reboot handler in these casesLogs
After reboot:
Calling Module
Own thoughts:
/etc/grub2.cfg
or grubby args is working around the existing tooling built into the OS and grub:Adding args should be done through templating files into
/etc/grub.d
for each override (RH Grubby Docs and StackOverflow example), such as/etc/grub.d/60-stackhpc-grubcmdline-quiet
then simply invokegrubby
orgrub-mkconfig
without argsRemoving entries would still edit
/etc/default/grub
, butansible.builtin.lineinfile
should do the "surgical cuts" instead to minimise the changes to the file rather than trying generate a "new" cmdline using Jinja templates (which could generate wrong and result in an unbootable machine).Alternatively, a grub script can be templated out
/etc/grub.d
which iterates over theGRUB_CMDLINE_LINUX*
variables and appends every argument back except the matching one using thefor in
andif
statements built into grub script. This would be more correct, but I don't have an adaptable example to hand.The biggest advantages are:
mv /etc/grub.d/*stackhpc-grubcmdline /etc/grub.d.bak && grubby ...
grubby
andnotify reboot
if any template /lineinfile
has changedIf not the above changes:
old_cmdline != kernel_cmdline | select() | sort | list
is potentially brittle as there will be more problems like this in the future. Instead it could be something akin to the following pseudo code:This would only check for keywords the user has explicitly set in the role, rather than being affected by parameters (such as
root=UUID=abc...
) which they have not specified at all. However, this still leaves the potential problems around directly generating/etc/default/grub
The text was updated successfully, but these errors were encountered: