> removing of boom-boot-grub2 subpackage, which is now obsolete. With BLS the default, it is not needed anymore"

No - this subpackage contained shell scripts that hooked into grub2-mkconfig to enable BLS and optionally allow a submenu to be used on releases that supported it (RHEL7). Since BLS is now enabled by default we don't need to ship those scripts or tell users to modify the Grub configuration in order to use boom.

> They no longer work in rhel9.1. Is this expected? 

They are there, and they do work, but the user now needs to enable them manually. This is not ideal - it's a consequence of the fact that we are no longer shipping "canned" profiles in the RHEL package that include the Red Hat-specific profile tweaks. This fact had slipped my mind when I updated bug 2089418 earlier (we have a heuristic to automatically set the --uname-pattern for RHEL and Fedora, and I think I incorrectly thought that we had covered this with a similar mechanism).

# boom profile create --from-host --optional-keys "grub_arg grub_users grub_class"
Created profile with os_id e0ef3eb:
  OS ID: "e0ef3ebf3862de64e4082062f0063422796dcca6",
  Name: "Red Hat Enterprise Linux", Short name: "rhel",
  Version: "9.0 (Plow)", Version ID: "9.0",
  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: "grub_arg grub_users grub_class", UTS release pattern: "el9"

# boom create --title "Boom Grub Optional Keys Test" --grub-users "foo bar" --root-lv rhel/root
Created entry with boot_id 3b7bb70:
  title Boom Grub Optional Keys Test
  machine-id 68f613d8774e41e792fad28212cfedae
  version 5.14.0-70.13.1.el9_0.x86_64
  linux /vmlinuz-5.14.0-70.13.1.el9_0.x86_64
  initrd /initramfs-5.14.0-70.13.1.el9_0.x86_64.img
  options root=/dev/rhel/root ro rd.lvm.lv=rhel/root
  grub_users foo bar
  grub_arg --unrestricted
  grub_class kernel

I can extend the --from-host heuristics to also handle this case; I don't think it's reasonable to expect users to be familiar with the quirks of Red Hat's extensions to the BLS spec and it's a lot of additional typing. Otherwise we'd need to document this for users who need to be able to configure the grub extension keys.

OK. I wasn't mis-remembering - we do have an existing mechanism to handle this. It was added in 2019 for boom-1.0 (RHEL7).

commit cd4794f130c883ccf27d8779628ab2f3f5a25d3b
Author: Bryn M. Reeves <bmr>
Date:   Tue Nov 26 21:04:09 2019 +0000

    boom.command: automatically set default optional_keys
    
    All distributions in the Red Hat "family" (Fedora, CentOS and
    Red Hat Enterprise Linux, as well as rebuilds/forks) are known
    to support the additional Red Hat-defined BLS keys. Automatically
    enable these keys when a corresponding OsProfile is created unless
    the user specifies an explicit value with --optional-keys.
    
    Signed-off-by: Bryn M. Reeves <bmr>

The table includes the RHEL7 "Server" and "Workstation" string variants, but was not updated when RHEL8 dropped these suffixes. This was not detected previously because we shipped built-in profiles for RHEL8.

This has now been fixed and also extends the automatic optional keys coverage to F35+ (which switched the NAME field from "Fedora" to "Fedora Linux"):

commit 514f3f014815c2bfe8d4a5a325c54ea34fb9cb4f (HEAD -> main)
Author: Bryn M. Reeves <bmr>
Date:   Tue Jun 14 09:31:33 2022 -0400

    boom.command: add new os-release values to Red Hat optional keys list
    
    Add "Red Hat Enterprise Linux" (NAME for el8 onwards), and "Fedora
    Linux" (NAME for fc35 onwards) to the table of names to automatically
    enable grub optional keys for.
    
    Signed-off-by: Bryn M. Reeves <bmr>

diff --git a/boom/command.py b/boom/command.py
index 0ef66ee..07c0616 100644
--- a/boom/command.py
+++ b/boom/command.py
@@ -1094,9 +1094,11 @@ def _default_optional_keys(osp):
     """
     all_optional_keys = "grub_users grub_arg grub_class id"
     _default_optional_keys = [
+        "Red Hat Enterprise Linux",
         "Red Hat Enterprise Linux Server",
         "Red Hat Enterprise Linux Workstation",
         "CentOS Linux",
+        "Fedora Linux",
         "Fedora"
     ]
     if osp.os_name in _default_optional_keys:

Appears to be working now. Marking verified in the latest rpm.

boom-boot-1.4-4.el9    BUILT: Thu Jul 14 01:20:05 AM CDT 2022


[root@hayes-03 ~]# boom create --title 10 --grub-arg 172 --root-lv /dev/snapper/boom_snap
Created entry with boot_id 366f282:
  title 10
  machine-id f59e551c77ff4b96901e02e6392ad713
  version 5.14.0-127.el9.x86_64
  linux /vmlinuz-5.14.0-127.el9.x86_64
  initrd /initramfs-5.14.0-127.el9.x86_64.img
  options root=/dev/snapper/boom_snap ro rd.lvm.lv=snapper/boom_snap
  grub_users $grub_users
  grub_arg 172
  grub_class kernel
[root@hayes-03 ~]# boom create --title 10 --grub-class 439 --root-lv /dev/snapper/boom_snap
Created entry with boot_id 3b36472:
  title 10
  machine-id f59e551c77ff4b96901e02e6392ad713
  version 5.14.0-127.el9.x86_64
  linux /vmlinuz-5.14.0-127.el9.x86_64
  initrd /initramfs-5.14.0-127.el9.x86_64.img
  options root=/dev/snapper/boom_snap ro rd.lvm.lv=snapper/boom_snap
  grub_users $grub_users
  grub_arg --unrestricted
  grub_class 439
[root@hayes-03 ~]# boom create --title 10 --grub-users 511 --root-lv /dev/snapper/boom_snap
Created entry with boot_id 6a8433b:
  title 10
  machine-id f59e551c77ff4b96901e02e6392ad713
  version 5.14.0-127.el9.x86_64
  linux /vmlinuz-5.14.0-127.el9.x86_64
  initrd /initramfs-5.14.0-127.el9.x86_64.img
  options root=/dev/snapper/boom_snap ro rd.lvm.lv=snapper/boom_snap
  grub_users 511
  grub_arg --unrestricted
  grub_class kernel

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (boom-boot bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8205