Bug 2120845 - grub2-mkconfig steps on the options line in all /boot/loader/entries/ conf files
Summary: grub2-mkconfig steps on the options line in all /boot/loader/entries/ conf files
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Javier Martinez Canillas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-23 21:22 UTC by Chris Murphy
Modified: 2024-05-21 14:15 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-21 14:15:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Chris Murphy 2022-08-23 21:22:54 UTC
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/

Comment 1 Bryn M. Reeves 2022-09-07 17:45:04 UTC
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.

Comment 2 Bryn M. Reeves 2022-09-07 19:02:29 UTC
> 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.

Comment 3 Chris Murphy 2022-09-07 19:33:19 UTC
(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.

Comment 4 Bryn M. Reeves 2022-09-08 12:45:05 UTC
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.

Comment 5 Chris Murphy 2022-09-23 20:51:38 UTC
See also bug 2118287.

Comment 6 Marta Lewandowska 2023-05-26 07:31:05 UTC
Chris,
if you pass --no-grubenv-update to grub2-mkconfig, do you get the results you were expecting?

Comment 7 Chris Murphy 2023-07-19 23:18:00 UTC
>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.

Comment 8 Aoife Moloney 2024-05-07 15:48:02 UTC
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.

Comment 9 Aoife Moloney 2024-05-21 14:15:52 UTC
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.


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