Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 40
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F40FinalFreezeException, FinalFreezeException
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:
Environment:
Last Closed: 2024-04-15 16:10:13 UTC
Type: ---
Embargoed:

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.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8c23e98d58
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.