Description of problem:
On a VM with mostly defaults, an attempt to change the kernel parameters by changing GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub are not reflected in /boot/grub2/grub.cfg after a rebuild of grub.cfg with grub2-mkconfig.
I can verify the system is using an msdos setup with MBR when looking through fdisk -l and gdisk -l /dev/vda and no grub.cfg files (or any files at all for that matter) exist under /boot/efi/EFI/redhat/.
Using grubby to change the parameters statically worked but the changes were made to /boot/loader/entries/<MACHINE_ID>-`uname -r`.conf which implies systemd-boot rather than grub. This confuses me some:
1) Considering the changes are made to /boot/loader/entries/<MACHINE_ID>-`uname -r`.conf and not in a grub.cfg file implicates the use of systemd-boot/bummiboot. However, what I am finding online in regards to systemd-boot is systemd-boot is EFI only (for example: https://bbs.archlinux.org/viewtopic.php?pid=1800372#p1800372). Is this to say systemd-boot is backwards compatible?
2) Grub has been in use for several major RHEL iterations; is there some method to make systemd-boot backwards compatible or grub tools forward compatible? For example, rebuilding grub.cfg would actually make the changes to the systemd-boot loader configs or changes to /etc/default/grub be incorporated into the loader configs?
I will need to write an article on this since there seems to be a change and looking to get answers here simply to have customer's ready for the change.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install a RHEL 8 Beta VM
- systemd-boot managed boot configs
- grub2 managed boot configs
- I work in the kernel space predominantly and not so much the boot manager area so if parts of this BZ are erroneously set, please do not hesitate to change them and let me know why so I may better understand how to file BZs like this in the future
Turns out this is expected behavior for some reason:
Any chance this will be made backwards/forward compatible?
*** This bug has been marked as a duplicate of bug 1637875 ***