 |
snapshot1.png (42,932 bytes)
snapshot2.png (48,300 bytes) |
 |
Why are you running grub2-mkconfig in the first place? It's not necessary on CentOS/RHEL as grubby does it all for you. |
|
|
Tested and confirmed. The grub2-mkconfig is removing 'boot=/dev/sda1' (or whatever your /boot device is). That needs to be added to /etc/default/grub prior to running grub2-mkconfig (which still isn't necessary or recommended on CentOS/RHEL). You can recover the installed system by editing the entry at the grub menu at boot time and appending boot=/dev/whatever to the end of the linux16/linuxefi line for the relevant kernel. |
|
|
Thanks for the test and for the feedback. The steps in the bug report are the result of troubleshooting after a failed load. Part of the load for the subject machine is to install kmod-nvidia-340xx. This allows better access to the graphics hardware, but doesn't play nice with plymouth, and the resulting boot-up screens are just plain ugly. I generally replace "rhgb" with "vga=845" in /etc/default/grub to clean up the boot screens. In this case, when combined with the security profile, it broke the load. You are correct, adding "boot=/dev/sda1" to /etc/default/grub (after the initial entry at the grub menu) allows the machine to boot normally. Many thanks once again! |
|
|
FYI, the CentOS supplied kernel packages contain a postscript that runs `new-kernel-pkg` which in turn invokes grubby to add the new kernel entry to grub2. The way that works is it takes the current entry and copies it and amends it for the new kernel version. It copies any parameters from the current kernel entry. This means that you can edit this file, make your change there and grubby will then propagate that to subsequent kernel installs. For belt and braces, you can also (and probably should) amend /etc/default/grub to contain the same changes but nothing in CentOS will ever run grub2-mkconfig unless an admin does. |
|
|
Great info, good to know. I didn't see anywhere in new-kernel-pkg to add the vga= or boot= parameters. However, I did test a kernel update + other updates via yum after having run grub2-mkconfig with the new parameters added to /etc/default/grub. All updates were successful. My test vm and production machine are both back in service. Thanks again for the assist. |
- Anonymous
