Closed trevor-vaughan closed 3 years ago
Testing this not having much luck, with
kernel_parameter{'consoleblank':
ensure => present,
value => '0',
}
Nothing much seems to happen,
I would have expected it to be visible in the following:
# grub2-editenv - list
saved_entry=8acfa3bfcd324a25b72ef69f6bf3caa1-4.18.0-240.1.1.el8_3.x86_64
kernelopts=root=UUID=52a70118-54f4-4c82-8316-86ae34073a0e ro console=ttyS0,115200 console=tty0 rd.auto net.ifnames=0 crashkernel=auto rhgb quiet
Using
Updated augeasproviders_core to 2.6.0 since grub was > 2.4.0
Same result.
Running with debug , with a parameter that was not set:
Notice: /Stage[main]/Main/Kernel_parameter[foo]/value: value changed ['bar'] to ['other']
Debug: Executing: '/usr/sbin/grub2-mkconfig'
Debug: /Stage[main]/Main/Kernel_parameter[foo]: The container Class[Main] will propagate my refresh event
So grub2-mkconfig is called.
and node reboots
# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt1)/boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64 root=UUID=52a70118-54f4-4c82-8316-86ae34073a0e ro console=ttyS0,115200 console=tty0 rd.auto net.ifnames=0 crashkernel=auto rhgb quiet consoleblank=0 foo=bar
So this seems okay.
It seems that grub2-mkconfig
has changed such that it now works.
It used to result in a non-bootable system.
@traylenator Any chance you can help pinpoint the 'fixed' version of grub? I can add code to avoid running things if we're on a broken version.
I'm honestly surprised at this, you can't do everything through the new BLS material so it seems like this would have resulted in a lot of broken systems.
My guess from the changelog alone is:
* Mon May 20 2019 Javier Martinez Canillas <javierm@redhat.com> - 2.02-68
- blscfg: fallback to default_kernelopts if BLS option field isn't set
Related: rhbz#1680572
* Tue Dec 11 2018 Javier Martinez Canillas <javierm@redhat.com> - 2.02-64
- Make grub2-mkconfig to honour GRUB_CMDLINE_LINUX in /etc/default/grub
Resolves: rhbz#1637875
Thanks, that makes sense.
I don't know that I have time to consolidate the BLS detection materials into Utils right now but we can at least make this safer.
It looks like the original version of the OS shipped with 2.02-66, so the 2.02-68 limit appears to be the correct one and appears to be fixed at the first minor update (by a large jump). So this should be largely a non-issue on updated systems (but the safety hook still makes sense).
Glad that matches, I do have old images I could boot and test if needed.
We probably should add the BLS options based off of #60 but it'll take some additional integration work to make sure it trickles down everywhere.
Well, it turns out that the version matching is going to be almost impossible to make vendor neutral. So....I'm going to mark it as supporting EL 8.1+ in the metadata for now.
@raphink Added a warning to the README and bumped the metadata deps. Will try to refactor to use BLS as I can.
@raphink So, Travis CI is timing out for an unknown reason. I can try mucking about with the travis.yml
but I think you either need to migrate to Travis.com or GitHub Actions.
Hold off on pushing this, debugging something in EL7
@traylenator Made an update to the way flush
was calling things. This appears to correct some issues in our fips
module tests. Can you take another poke to see if it works for you?
Currently having some issues with el8 and FIPS mode. They broke something in the stack and I'm trying to figure out what. Prior to 8.3 everything was fine.
@raphink Managed to speed up the travis tests. Also, this is now working as expected.
Rebased for a single commit.
Fixed:
flush
functions to call the 'global update' mkconfig which was added asPuppetX::AugeasprovidersGrub::Util.mkconfig
Added:
Closes #63