Bug 2120845

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.