Description of problem: /boot/loader/entries contains multiple conf entries for different Fedora OS's When I run grub2-mkconfig, it unconditionally replaces the entire options line for all conf files in /boot/loader/entries. Version-Release number of selected component (if applicable): grub2-common-2.06-44.fc37.noarch grub2-common-2.06-52.fc37.noarch Does not seem to be a recent regression. How reproducible: Always Steps to Reproduce: 1. Mixed Fedora release versions 36 and 37 in a shared /boot/loader/entries, including entries that have a different machine ID. 2. Fedora 37 is currently booted 3. grub2-mkconfig -o /boot/grub2/grub.cfg Actual results: All conf files are modified. Example 1: # cat 799c3cd1115b414cbe5c030fc6dc0d16-0-rescue.conf title Fedora Linux (0-rescue-799c3cd1115b414cbe5c030fc6dc0d16) 36 (Workstation Edition) version 0-rescue-799c3cd1115b414cbe5c030fc6dc0d16 linux /boot/vmlinuz-0-rescue-799c3cd1115b414cbe5c030fc6dc0d16 initrd /boot/initramfs-0-rescue-799c3cd1115b414cbe5c030fc6dc0d16.img options root=UUID=b0cdab05-5632-4170-9610-d6ae158f8ec3 ro rootflags=subvol=root36.rescue fstab=no systemd.volatile=overlay grub_users $grub_users grub_arg --unrestricted grub_class fedora In this case grub2-mkconfig removes many important things about this snippet: - options root=UUID=b0cdab05-5632-4170-9610-d6ae158f8ec3 ro rootflags=subvol=root36.rescue fstab=no systemd.volatile=overlay + options root=UUID=b0cdab05-5632-4170-9610-d6ae158f8ec3 ro rootflags=subvol=root37 rhgb quiet It doesn't matter if grub2-mkconfig uses /etc/kernel/cmdline or /proc/cmdline. It's removing important parameters unique to *this* particular snippet, and completely breaks it. Example 2: # cat 799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64.conf title Fedora Linux (5.18.15-200.fc36.x86_64) 36 (Workstation Edition) version 5.18.15-200.fc36.x86_64 linux /boot/vmlinuz-5.18.15-200.fc36.x86_64 initrd /boot/initramfs-5.18.15-200.fc36.x86_64.img options root=UUID=b0cdab05-5632-4170-9610-d6ae158f8ec3 ro rootflags=subvol=root36 rhgb quiet grub_users $grub_users grub_arg --unrestricted grub_class fedora - options root=UUID=b0cdab05-5632-4170-9610-d6ae158f8ec3 ro rootflags=subvol=root36 rhgb quiet + options root=UUID=b0cdab05-5632-4170-9610-d6ae158f8ec3 ro rootflags=subvol=root37 rhgb quiet This also completely breaks this snippet. The subvolume root37 does not have this version of the kernel installed, so we'll end up in dracut. Example 3 is hypothetical, there aren't yet other consumers of BLS that I know of, but if they do exist, we step on their snippets and break boot of those OS's. Expected results: We are either going to follow Boot Loader Spec, or we aren't. Right now we're in a dangerous in-between situation where Fedora uses the BLS snippets and format, but the patches to grub2-mkconfig violate the most central purpose of BLS's existence which is a shared $BOOT for the purpose of deconflicting multiboot systems. I think 0061-Add-BLS-support-to-grub-mkconfig.patch should be modified so that certain options (boot parameters) are not modified in favor of everything that's in /etc/kernel/cmdline: root, rootflags, and probably all of rd.* but at least rd.md.uuid, rd.luks.uuid, rd.lvm.* I have no idea what Stratis uses to define $ROOT but expect it's similar to LVM so it also needs protection. Additional info: See bug 2032680, which lead to https://src.fedoraproject.org/rpms/grub2/c/3e40727f723213b92defb8df7396e6c579480483?branch=rawhide expanded the behavior already in 0061-Add-BLS-support-to-grub-mkconfig.patch leading to the above issues, i.e. Fedora grub2-mkconfig does not exclusively create a grub.cfg, it can modify the options line in BLS snippets. http://systemd.io/BOOT_LOADER_SPECIFICATION/
This change also affects any boom managed BLS boot entries that the user may have created (for e.g. to boot a snapshot of the system state). With grub2-common-2.06-29.fc36.noarch the options line is rewritten unconditionally: # dnf -y install boom-boot # boom profile create --from-host --uname-pattern fc36 Created profile with os_id 9b9c73a: OS ID: "9b9c73a3a6e41675f0b63058f5584458d5877d8f", Name: "Fedora Linux", Short name: "fedora", Version: "36 (Workstation Edition)", Version ID: "36", Kernel pattern: "/vmlinuz-%{version}", Initramfs pattern: "/initramfs-%{version}.img", Root options (LVM2): "rd.lvm.lv=%{lvm_root_lv}", Root options (BTRFS): "rootflags=%{btrfs_subvolume}", Options: "root=%{root_device} ro %{root_opts}", Title: "%{os_name} %{os_version_id} (%{version})", Optional keys: "", UTS release pattern: "fc36" # boom create "This is a test entry" --root-dev /dev/vda2 --add-opts debug --del-opts "rhgb quiet" WARNING - Options for BootEntry(boot_id=82798dc) do not match OsProfile: marking read-only WARNING - Options for BootEntry(boot_id=2608c0f) do not match OsProfile: marking read-only Created entry with boot_id fbc29a9: title Fedora Linux 36 (5.17.5-300.fc36.x86_64) machine-id 107387fd491147039c57dafb6a6fb187 version 5.17.5-300.fc36.x86_64 linux /vmlinuz-5.17.5-300.fc36.x86_64 initrd /initramfs-5.17.5-300.fc36.x86_64.img options root=/dev/vda2 ro debug # boom list WARNING - Options for BootEntry(boot_id=82798dc) do not match OsProfile: marking read-only WARNING - Options for BootEntry(boot_id=2608c0f) do not match OsProfile: marking read-only BootID Version Name RootDevice 82798dc 5.17.5-300.fc36.x86_64 Fedora Linux UUID=dc4cfff9-1bef-4ca5-b9b9-b9497dfb6a41 fbc29a9 5.17.5-300.fc36.x86_64 Fedora Linux /dev/vda2 # grub2-mkconfig -o /boot/grub2/grub.cfg.new Generating grub configuration file ... Adding boot menu entry for UEFI Firmware Settings ... WARNING - Options for BootEntry(boot_id=82798dc) do not match OsProfile: marking read-only WARNING - Options for BootEntry(boot_id=2608c0f) do not match OsProfile: marking read-only WARNING - Options for BootEntry(boot_id=8a52fa5) do not match OsProfile: marking read-only <<< Entry fbc29a9 has been modified done # cat /boot/loader/entries/107387fd491147039c57dafb6a6fb187-fbc29a9-5.17.5-300.fc36.x86_64.conf #OsIdentifier: 9b9c73a3a6e41675f0b63058f5584458d5877d8f title Fedora Linux 36 (5.17.5-300.fc36.x86_64) machine-id 107387fd491147039c57dafb6a6fb187 version 5.17.5-300.fc36.x86_64 linux /vmlinuz-5.17.5-300.fc36.x86_64 initrd /initramfs-5.17.5-300.fc36.x86_64.img options root=UUID=dc4cfff9-1bef-4ca5-b9b9-b9497dfb6a41 ro rootflags=subvol=root rhgb quiet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The options line should have remained as: options root=/dev/vda2 ro debug One simple option would be to restrict the entry updates during grub2-mkconfig to only files that match the file names used by the system entries; boom managed entries can be distinguished because they include the short boot_id in the file name. A possible mitigating factor is that it's fairly rare to actually run grub2-mkconfig these days (mostly seems to be users trying to recover from "can't boot" scenarios, or specific configurations where boom is not likely to be used), although as shown above simply running the command and not updating grub.cfg is sufficient to re-write the boot entries.
> I have no idea what Stratis uses to define $ROOT but expect it's similar to LVM so it also needs protection. Stratis boot syntax is fairly straightforward: stratis.rootfs.pool_uuid=fc7257c6-596a-4ed0-a043-dd1f341a7a21 root=/dev/stratis/pool1/fs1 We support it in boom, although it's not currently possible to install to a Stratis rootfs directly using Anaconda.
(open)SUSE have been discussing BLS adoption for a couple of years. I started a thread on their development list to see about current perspective. They are still interested, and have a proof of concept for traditional and microOS installations. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/TFX5X6WFSWKCQGEQ6K7NAEJVUXE4RPA2/ Therefore, along with boom, unforced real world examples of compliant BLS implementations do exist. One possible way forward is adding carve out exceptions for certain "$ROOT determining" boot parameters (added to Description). Another option might be duping the entries, and modifying the dups. This leads to growing clutter, but also doesn't render a system unbootable.
I think these components are under various pressures and it's understandable that compromises sometimes have to be made to keep everything working. That said, I do think that this change is problematic as currently implemented and I am hopeful we can find a way forward that works for all the different use cases. I think the biggest outstanding question for me at the moment is why the switch to the new machine-id doesn't take place during systemd-firstboot (which is presumably responsible for setting up the "new" machine-id?). It seems like this is the ideal place to re-write entries, since both the old and new machine-id are known, and in the image deployment scenario there won't be any additional boot entries to potentially interfere with. It seems like trying to do this later, at each invocation of grub2-mkconfig is always going to be error prone and potentially lead to unwanted changes and unbootable entries.
See also bug 2118287.
Chris, if you pass --no-grubenv-update to grub2-mkconfig, do you get the results you were expecting?
>if you pass --no-grubenv-update to grub2-mkconfig, do you get the results you were expecting? In that case, none of the BLS snippets in /boot/loader/entries is touched. The expectation is the grub2-mkconfig and grubby only modify the boot loader snippets it owns. They used to do this but not since the introduction of /etc/kernel/cmdline There should be a grubby equivalent of this bug but I'm not finding it at the moment.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.