Bug 2422116

Summary:	grubby requires specifying subvolume name when /boot is on btrfs
Product:	[Fedora] Fedora	Reporter:	Chris Murphy <bugzilla>
Component:	grubby	Assignee:	Peter Jones <pjones>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	43	CC:	btrfs-sig, davide, lsandova, nfrayer, ngompa13, omosnacek, pjones
Target Milestone:	---	Flags:	omosnacek: needinfo? (pjones)
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Murphy 2025-12-14 22:53:16 UTC

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:

Comment 1 Ondrej Mosnáček 2026-05-18 13:51:27 UTC

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+ :(

Comment 2 Ondrej Mosnáček 2026-05-18 13:56:21 UTC

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

Comment 3 Leo Sandoval 2026-05-18 19:04:55 UTC

(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.