Bug 1656449 - Systemd-boot is in use for a BIOS/MBR setup by default and changes to /etc/default/grub are not reflected
Summary: Systemd-boot is in use for a BIOS/MBR setup by default and changes to /etc/de...
Status: CLOSED DUPLICATE of bug 1637875
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: grub2
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: rc
: 8.0
Assignee: Bootloader engineering team
QA Contact: Release Test Team
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-05 14:35 UTC by Charles Haithcock
Modified: 2018-12-10 17:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-10 17:58:58 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3710121 0 None None None 2018-12-05 17:44:10 UTC

Description Charles Haithcock 2018-12-05 14:35:19 UTC
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):

- kernel-4.18.0-40.el8.x86_64
- systemd-239-8.el8.x86_64
- grubby-8.40-28.el8.x86_64
- grub2-tools-2.02-59.el8.x86_64

How reproducible:
- 100%

Steps to Reproduce:
1. Install a RHEL 8 Beta VM

Actual results:
- systemd-boot managed boot configs

Expected results:
- grub2 managed boot configs

Additional info:
- 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

Comment 1 Charles Haithcock 2018-12-05 17:43:43 UTC
Turns out this is expected behavior for some reason: 


Any chance this will be made backwards/forward compatible?

Comment 2 Javier Martinez Canillas 2018-12-10 17:58:58 UTC

*** This bug has been marked as a duplicate of bug 1637875 ***

Note You need to log in before you can comment on or make changes to this bug.