Bug 2271674 - kernel-install detecting btrfs/ext4/etc partitions mounted at /boot as XBOOTLDR
Summary: kernel-install detecting btrfs/ext4/etc partitions mounted at /boot as XBOOTLDR
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 40
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F40FinalFreezeException
TreeView+ depends on / blocked
Reported: 2024-03-26 21:20 UTC by Jeremy Linton
Modified: 2024-04-15 16:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-04-15 16:10:13 UTC
Type: ---

Attachments (Terms of Use)

Description Jeremy Linton 2024-03-26 21:20:03 UTC
Systemd 255.4-1.fc40.

Normal EFI systems cannot read non FAT/ESP partitions, yet systemd-boot keeps trying to use a XBOOTLDR similar to the way grub has linux filesystem knowledge for reading BLS/etc files. 

The latest kernel-install is detecting ext4/btrfs/etc partitions mounted at /boot as XBOOTLDR despite systemd-boot being unable to read them.

This regresses previous behavior where XBOOTLDR partitions are ignored unless explicitly configured.

Reproducible: Always

Steps to Reproduce:
1. Use default F40, inst.sdboot anaconda option
2. Fail to delete the /boot mountpoint.
3. Install fails because its placing kernel/initrd files in /boot rather than /boot/efi/machine-id
4. Run `kernel-install -v list` note its confused about the machines ability and where it should be placing loader entries/etc despite the fact that the filesystem has an entries.srel/etc files in /boot/efi/loader/entries/entries.srel

Expected Results:  
It should work with or without a filesystem that systemd-boot cannot read mounted at /boot

Comment 1 Jeremy Linton 2024-03-26 21:37:23 UTC
To simplify this to a single sentence kernel-install should not assume /boot is a XBOOTLDR unless its fat/ESP.

Comment 2 Jeremy Linton 2024-03-26 22:35:56 UTC
For systemd-boot of course.. if that wasn't clear.

Comment 3 Fedora Update System 2024-03-27 00:02:37 UTC
FEDORA-2024-8c23e98d58 (sdubby-1.0-8.fc40) has been submitted as an update to Fedora 40.

Comment 4 Fedora Update System 2024-03-27 02:36:16 UTC
FEDORA-2024-8c23e98d58 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8c23e98d58`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8c23e98d58

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Blocker Bugs Application 2024-04-05 20:02:36 UTC
Proposed as a Freeze Exception for 40-final by Fedora user jlinton using the blocker tracking app because:

 Without this inst.sdboot is again broken in the default filesystem configuration anaconda uses. There is a workaround, which requires the user to delete the /boot partition but that isn't ideal since it was working before systemd/kernel-install changed the way it detects XBOOTLDR.  I should have pushed to get this in under the freeze date but it missed by one day since it was sitting in -testing for a week.

This change should be transparent to non systemd-boot users, so the chance of breaking grub/etc systems should be ~0%.

Comment 6 Adam Williamson 2024-04-07 14:55:33 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1568 , marking accepted.

Comment 7 Fedora Update System 2024-04-08 00:12:35 UTC
FEDORA-2024-8c23e98d58 (sdubby-1.0-8.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 8 Adam Williamson 2024-04-10 00:53:53 UTC
Is there still anything to do here or can we close this?

Comment 9 Jeremy Linton 2024-04-15 16:10:13 UTC
Looks good, I just retested with the server dvd too.

Thanks everyone.

Note You need to log in before you can comment on or make changes to this bug.