incorrect path for kernel and initrd

[birb57]

Hello

when creating my boom emtry with below command (on EFI system without /boot dedicated filesystem) path for kernel and initrd is incorrect (missing /boot)

boom create --title "Root Snapshot - before backup" --rootlv SysVGSystem/Root_snap -V

index=0
kernel="/vmlinuz-4.18.0-477.55.1.el8_8.x86_64"
args="ro rd.lvm.lv=SysVGSystem/Root_snap rhgb quiet"
root="/dev/SysVGSystem/Root_snap"
initrd="/initramfs-4.18.0-477.55.1.el8_8.x86_64.img"
title="Root Snapshot - before backup"
id="21c51331679049e4f8bc47272142ceec-ac7f556-4.18.0-477.55.1.el8_8.x86_64"

Missing /boot....

Thanks for your advise

[bmr-cymru]

Hello @birb57,

Thanks for filing an issue. I was out on vacation last week so sorry for the slow response.

I'm not sure exactly what's going on here right now but I will run some tests here this week. Normally grubby prepends the /boot prefix when displaying boot entries - if you examine the BLS files on a default RHEL8 UEFI layout you'll see that they give the path relative to the root of /boot, e.g.:

# cat /boot/loader/entries/18fa4eb9191e4519a24fe35c3ff6db1d-4.18.0-513.5.1.el8_9.x86_64.conf 
title Red Hat Enterprise Linux (4.18.0-513.5.1.el8_9.x86_64) 8.9 (Ootpa)
version 4.18.0-513.5.1.el8_9.x86_64
linux /vmlinuz-4.18.0-513.5.1.el8_9.x86_64 <<<
initrd /initramfs-4.18.0-513.5.1.el8_9.x86_64.img $tuned_initrd <<<
options $kernelopts $tuned_params
id rhel-20230929092625-4.18.0-513.5.1.el8_9.x86_64
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

# grubby --info=1
index=1
kernel="/boot/vmlinuz-4.18.0-513.5.1.el8_9.x86_64" <<<
args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet $tuned_params"
root="/dev/mapper/rhel-root"
initrd="/boot/initramfs-4.18.0-513.5.1.el8_9.x86_64.img $tuned_initrd" <<<
title="Red Hat Enterprise Linux (4.18.0-513.5.1.el8_9.x86_64) 8.9 (Ootpa)"
id="18fa4eb9191e4519a24fe35c3ff6db1d-4.18.0-513.5.1.el8_9.x86_64"

This is with the default partitioning configuration for LVM, with a separate /boot partition:

# lsblk 
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0            11:0    1 1024M  0 rom  
vda           252:0    0   20G  0 disk 
├─vda1        252:1    0  600M  0 part /boot/efi
├─vda2        252:2    0    1G  0 part /boot
└─vda3        252:3    0   14G  0 part 
  ├─rhel-root 253:0    0   12G  0 lvm  /
  └─rhel-swap 253:1    0    2G  0 lvm  [SWAP]

Are you able to boot from the boom-managed entries on your system? And just to confirm, when you say without dedicated /boot filesystem your /boot is part of the root filesystem?

[bmr-cymru]

I'm having a bit of trouble re-creating your configuration in the installer: if I remove the /boot filesystem Anaconda raises an error that /boot cannot be of type lvmlv:

If I try to make /boot into the EFI System Partition I get an error that the ESP must be mounted at /boot/efi:

How did you create this configuration, and could you post the output of the lsblk command for your system?

Thanks,

[bmr-cymru]

Using the default UEFI layout I'm not able to reproduce the problem you're having:

# boom create --title "Test" --root-lv rhel/root
Created entry with boot_id 225cf1e:
  title Test
  machine-id 18fa4eb9191e4519a24fe35c3ff6db1d
  version 4.18.0-513.5.1.el8_9.x86_64
  linux /vmlinuz-4.18.0-513.5.1.el8_9.x86_64
  initrd /initramfs-4.18.0-513.5.1.el8_9.x86_64.img
  options root=/dev/rhel/root ro rd.lvm.lv=rhel/root rhgb quiet
  grub_users $grub_users
  grub_arg --unrestricted
  grub_class kernel

# grubby --info=0
index=0
kernel="/boot/vmlinuz-4.18.0-513.5.1.el8_9.x86_64"
args="ro rd.lvm.lv=rhel/root rhgb quiet"
root="/dev/rhel/root"
initrd="/boot/initramfs-4.18.0-513.5.1.el8_9.x86_64.img"
title="Test"
id="18fa4eb9191e4519a24fe35c3ff6db1d-225cf1e-4.18.0-513.5.1.el8_9.x86_64"

[bskou57]

Hello bmr-cymru

Find below screenshot of my grub when trying to boot normal boom recovery entry (under efi)

[bskou57]

[bskou57]

[bskou57]

As work arround I add /boot in grub2 BLS file 👍
$ more 21c51331679049e4f8bc47272142ceec-4.18.0-553.5.1.el8_10.x86_64.conf
title Red Hat Enterprise Linux (4.18.0-553.5.1.el8_10.x86_64) 8.10 (Ootpa)
version 4.18.0-553.5.1.el8_10.x86_64
linux /boot/vmlinuz-4.18.0-553.5.1.el8_10.x86_64
initrd /boot/initramfs-4.18.0-553.5.1.el8_10.x86_64.img $tuned_initrd
options $kernelopts $tuned_params
id rhel-20240521075226-4.18.0-553.5.1.el8_10.x86_64
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

[bskou57]

issue is present only with vm unde efi

NAME                            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                               8:0    0   80G  0 disk 
├─sda1                            8:1    0  200M  0 part /boot/efi
└─sda2                            8:2    0 79.8G  0 part 
  ├─SysVGSystem-Root-real       253:0    0   12G  0 lvm  
  │ ├─SysVGSystem-Root          253:1    0   12G  0 lvm  /
  │ └─SysVGSystem-Root_snap     253:3    0   12G  0 lvm  
  ├─SysVGSystem-Var-real        253:4    0   16G  0 lvm  
  │ ├─SysVGSystem-Var           253:5    0   16G  0 lvm  /var
  │ └─SysVGSystem-Var_snap      253:7    0   16G  0 lvm  
  ├─SysVGSystem-Opt-real        253:8    0    4G  0 lvm  
  │ ├─SysVGSystem-Opt           253:9    0    4G  0 lvm  /opt
  │ └─SysVGSystem-Opt_snap      253:11   0    4G  0 lvm  
  ├─SysVGSystem-Swap            253:12   0    4G  0 lvm  [SWAP]
  ├─SysVGSystem-Var_Tmp         253:13   0    6G  0 lvm  /var/tmp
  ├─SysVGSystem-Tmp             253:14   0    2G  0 lvm  /tmp
  ├─SysVGSystem-local-real      253:15   0  512M  0 lvm  
  │ ├─SysVGSystem-local         253:16   0  512M  0 lvm  /local
  │ └─SysVGSystem-local_snap    253:18   0  512M  0 lvm  
  ├─SysVGSystem-local_snap-cow  253:17   0  512M  0 lvm  
  │ └─SysVGSystem-local_snap    253:18   0  512M  0 lvm  
  ├─SysVGSystem-appl-real       253:19   0  512M  0 lvm  
  │ ├─SysVGSystem-appl          253:20   0  512M  0 lvm  /appl
  │ └─SysVGSystem-appl_snap     253:22   0  512M  0 lvm  
  ├─SysVGSystem-appl_snap-cow   253:21   0  512M  0 lvm  
  │ └─SysVGSystem-appl_snap     253:22   0  512M  0 lvm  
  ├─SysVGSystem-usr_home        253:23   0  512M  0 lvm  /usr/home
sdb                               8:16   0   40G  0 disk 
├─SysVGSystem-Root_snap-cow     253:2    0    4G  0 lvm  
│ └─SysVGSystem-Root_snap       253:3    0   12G  0 lvm  
├─SysVGSystem-Var_snap-cow      253:6    0    4G  0 lvm  
│ └─SysVGSystem-Var_snap        253:7    0   16G  0 lvm  
└─SysVGSystem-Opt_snap-cow      253:10   0    2G  0 lvm  
  └─SysVGSystem-Opt_snap        253:11   0    4G  0 lvm 

Thanks for your help

[bmr-cymru]

It's still not clear to me how you set up your system this way - can you outline the steps you took to set up a system like this with no separate /boot using Anaconda (or however it was set up)? I can't find a way to recreate this here which I would need to do to try to provide an automated solution for this type of configuration. Even adding the /root/anaconda-ks.cfg from the installed system might provide some clues.

Anyway, in the meantime you can configure the OsProfile used on the system to automatically include the /boot path in generated boot entries - this is better than editing the boom managed BLS files (which will mess up the boot_id of the entry).

To do this delete any existing boom-managed boot entries and the pre-existing RHEL8 OsProfile, e.g.:

[root@localhost ~]# boom profile list
OsID    Name                            OsVersion               
8896596 Fedora                          30 (Workstation Edition)
4abe4f7 Red Hat Enterprise Linux        8 (Ootpa)               
72e3679 Red Hat Enterprise Linux Server 7.7 (Maipo)             
4aff687 Red Hat Enterprise Linux Server 7.8 (Maipo)    
[root@localhost ~]# boom profile delete 4abe4f7
Deleted 1 profile

Set up a new RHEL8 OsProfile that includes the /boot path in the kernel pattern and initramfs pattern templates:

[root@localhost ~]# boom profile create --from-host --kernel-pattern "/boot/vmlinuz-%{version}" --initramfs-pattern "/boot/initramfs-%{version}.img"
Created profile with os_id 43747d3:
  OS ID: "43747d3888b663d2bc88efd35d0813159a84d291",
  Name: "Red Hat Enterprise Linux", Short name: "rhel",
  Version: "8.9 (Ootpa)", Version ID: "8.9",
  Kernel pattern: "/boot/vmlinuz-%{version}", Initramfs pattern: "/boot/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: "el8"

The path will now be automatically included in any new boot entries you create, e.g.:

[root@localhost ~]# boom create --title "PathTest" --root-lv rhel/root
Created entry with boot_id 88b5ed4:
  title PathTest
  machine-id 696cab08b9fe462fae1369130541ccf3
  version 4.18.0-513.5.1.el8_9.x86_64
  linux /boot/vmlinuz-4.18.0-513.5.1.el8_9.x86_64
  initrd /boot/initramfs-4.18.0-513.5.1.el8_9.x86_64.img
  options root=/dev/rhel/root ro rd.lvm.lv=rhel/root

You can confirm the path is present in the files generated under /boot/loader/entries:

[root@localhost ~]# cat /boot/loader/entries/696cab08b9fe462fae1369130541ccf3-88b5ed4-4.18.0-513.5.1.el8_9.x86_64.conf 
#OsIdentifier: 43747d3888b663d2bc88efd35d0813159a84d291
title PathTest
machine-id 696cab08b9fe462fae1369130541ccf3
version 4.18.0-513.5.1.el8_9.x86_64
linux /boot/vmlinuz-4.18.0-513.5.1.el8_9.x86_64
initrd /boot/initramfs-4.18.0-513.5.1.el8_9.x86_64.img
options root=/dev/rhel/root ro rd.lvm.lv=rhel/root

[bmr-cymru]

As work arround I add /boot in grub2 BLS file 👍

$ more 21c51331679049e4f8bc47272142ceec-4.18.0-553.5.1.el8_10.x86_64.conf
title Red Hat Enterprise Linux (4.18.0-553.5.1.el8_10.x86_64) 8.10 (Ootpa) version 4.18.0-553.5.1.el8_10.x86_64
linux /**boot**/vmlinuz-4.18.0-553.5.1.el8_10.x86_64
initrd /**boot**/initramfs-4.18.0-553.5.1.el8_10.x86_64.img $tuned_initrd
options $kernelopts $tuned_params id rhel-20240521075226-4.18.0-553.5.1.el8_10.x86_64
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

Note that this isn't a boom-managed boot entry - this is the system provided boot entry for kernel 4.18.0-553.5.1.el8_10.x86_64. You may need to report this against the systemd package (which provides kernel-install) and or/grubby if the system provided boot entries have the wrong path.