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.