Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: when /boot is on btrfs, grubby seems to expect PATH to kernel to use the subvolume name rather than the mounted path, when setting the default kernel to boot Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: The kernels to boot are on a dedicated Btrfs, in a subvolume named "boot43" which is mounted at /boot # grubby --set-default=/boot/vmlinuz-6.18.1-200.fc43.x86_64 The param /boot/vmlinuz-6.18.1-200.fc43.x86_64 is incorrect # grubby --set-default=/boot/boot/vmlinuz-6.18.1-200.fc43.x86_64 The param /boot/boot/vmlinuz-6.18.1-200.fc43.x86_64 is incorrect # grubby --set-default=/boot43/boot/vmlinuz-6.18.1-200.fc43.x86_64 The param /boot43/boot/vmlinuz-6.18.1-200.fc43.x86_64 is incorrect # grubby --set-default=/boot43/vmlinuz-6.18.1-200.fc43.x86_64 The default is /boot/loader/entries/2a837d3749fd4397a3107adde82b7518-6.18.1-200.fc43.x86_64.conf with index 0 and kernel /boot/boot43/vmlinuz-6.18.1-200.fc43.x86_64 # Actual results: --set-default=kernel-path seems to need the path from the perspective of GRUB, which I guess is /boot43/mlinuz-6.18.1-200.fc43.x86_64 But then the output from that command reports back a different path that is confusing no matter the perspective - /boot/boot43/vmlinuz does not exist either as assembled during startup or in the pre-boot environment. Expected results: I'm expecting it shouldn't matter if this is on Btrfs or in a subvolume, and the tool should do whatever lookup is required behind the scene to set the path accordingly so that GRUB will boot the selected kernel Additional info:
This breaks also updating boot params of existing kernels on Fedora Cloud images: # grubby --update-kernel /boot/vmlinuz-6.19.10-300.fc44.x86_64 --args nokaslr The param /boot/vmlinuz-6.19.10-300.fc44.x86_64 is incorrect On the cloud image the subvolume is named just "boot", so the path in the BLS file is "/boot/vmlinuz-...". grubby seems to detect that /boot is a mountpoint, and then just strips the "/boot" prefix from the --update-kernel arg ("/boot/vmlinuz-6.19.10-300.fc44.x86_64" -> "/vmlinuz-6.19.10-300.fc44.x86_64") and matches the result with the BLS value, which does have the "/boot" prefix, though. In this case the only workaround is to supply "/boot/boot/vmlinuz-...", which is nonsense... @pjones Can you (or someone from the BTRFS SIG) please fix this? It makes grubby pretty much unusable on Fedora Cloud 44+ :(
For now I at least submitted this PR, which doesn't fix the bug, but at least improves the situation (by making `grubby --update-kernel vmlinuz-... ...` work): https://src.fedoraproject.org/rpms/grubby/pull-request/30
(In reply to Ondrej Mosnáček from comment #2) > For now I at least submitted this PR, which doesn't fix the bug, but at > least improves the situation (by making `grubby --update-kernel vmlinuz-... > ...` work): > https://src.fedoraproject.org/rpms/grubby/pull-request/30 LGTM but I ask Marta to review it also.