kernel_parameters set incorrectly on CentOS 8

[traylenator]

I realise the module does not currently claim to support CentoOS 8.

With centos8

/etc/default/grub

is no longer the way to specify kernel parameters and indeed grub2-mkconfig is no
longer the correct command to call.

From https://access.redhat.com/solutions/3710121 (paywall) suggests that

# grub2-editenv - list
saved_entry=72ee326dc9ff4092ab35d066fbbf02c5-4.18.0-147.8.1.el8_1.x86_64
kernelopts=root=UUID=8dd1149a-2dab-4b33-b554-42890f94d1b1 ro console=ttyS0,115200 console=tty0 rd.auto net.ifnames=0 crashkernel=auto rhgb quiet

and

grub2-editenv - set "kernelopts=root=UUID=8dd1149a-2dab-4b33-b554-42890f94d1b1 ro console=ttyS0,115200 console=tty0 rd.auto net.ifnames=0 crashkernel=auto rhgb quiet consoleblank=0"

is the way to set consoleblank.

In reality this command maintains the files:

# ls -l /boot/efi/EFI/centos/grubenv /boot/grub2/grubenv
-rwx------. 1 root root 1029 May 22 17:01 /boot/efi/EFI/centos/grubenv
lrwxrwxrwx. 1 root root   25 Feb  5 02:46 /boot/grub2/grubenv -> ../efi/EFI/centos/grubenv

and these are loaded by the blscfg module.

https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

Not sure how to proceed. Can we still use augeas to validate output of the commands
to add kernel_parameters.

[traylenator]

I see there is grubenv work in the menu_config type for some inspiration.

[trevor-vaughan]

@traylenator I'm currently doing a bit of testing and it looks like everything still works as expected as long as GRUB_ENABLE_BLSCFG=true in /etc/default/grub.

[traylenator]

@trevor-vaughan what do you mean by still works? It does edit files but when I tested a long time ago these are not used on reboot.

[trevor-vaughan]

@traylenator The bug fix you added to run mkconfig on all files in menuentry needs to be ported to the other providers. Working on that now as part of #63

[chowbok]

Not to be a pest, but will the fix be put in anytime soon? We really need it for a RHEL 8 deploy.

[raphink]

Which fix is that? I'm not sure there's a PR associated to that issue at the moment.

[trevor-vaughan]

@raphink I'm assuming this one #64

[traylenator]

So this is all fixed now assuming you are running 8.3.

Running with 8.1 or 8.2 results in a non bootable system.