systemd-boot fails after updating systemd to 252.3 #25737
Comments
crondrift
changed the title
yuwata
added
the
regression ⚠️
|
Does sd-boot from v252, v252.1 or v252.2 work? If possible can you do a regression test (between |
poettering
added
the
needs-reporter-feedback ❓
|
bluca
removed
the
needs-reporter-feedback ❓
|
I don't see how any commits in between could cause this. Which version of v252.2 did you check? There is v252.2-1 to v252.2-4. For the non-working sd-boot, do you see a device path for that entry in the listing if you press Also, the output of |
yuwata
added
the
needs-reporter-feedback ❓
|
@medhefgo
System: Current Boot Loader: Random Seed: Available Boot Loaders on ESP: Boot Loaders Listed in EFI Variables: Boot Loader Entries: Default Boot Loader Entry: |
yuwata
removed
the
needs-reporter-feedback ❓
|
The device path showing in v252.3 is just weird as the device handle changing is the only thing I can think of that could cause the error. The culprits should be one of the December 8 commits on stable: https://github.com/systemd/systemd-stable/commits/v252-stable/src/boot/efi (probably either 87add68 or 1c9e7fc). But really, neither of these should be causing this… Can you check whether the latest git main branch works? (Ideally a regression test so I don't have to make a guess to which commit is the culprit.) |
|
I did a regression test starting with defining
b99bf58 is the first bad commit |
Connecting console devices making the ESP suddenly inaccessible makes no sense to me, are you sure this is the one? Can you try this branch, hopefully that will fix it (or at least tell me which call exactly is failing): https://github.com/medhefgo/systemd/tree/boot-fixes You plug one hole and another firmware gets their panties in a bunch. EFI vendors are gonna drive me insane. |
|
This time, the error is slightly different. I tried my best and I'm not sure, if I did it right.
What's also curious...on every version that fails, the boot menu doesn't show as normal. It's alligned to the left and the entries only pop up one after another, when you select them with the arrow keys (sorry for the bad quality, but I think you get the idea).
|
|
Please try the attached PR to see if it fixes your issue. |
|
I've tested it. Now everything is working again as expected: bootloader menu is back to normal, system boots fine. |
Can you explain how you did it? I'm struggling with updating systemd |
|
I've built the bootloader binary from this branch: https://github.com/medhefgo/systemd/tree/boot-fixes |
… devices" This reverts commit b99bf58. It seems that using this protocol on some firmwares to forcibly initialize console devices may break handles (already opened file handles and the device handle itself) that we rely on to access the boot filesystem, making it impossible to load the selected entry. It might be possible to get a new handle by querying for the device handle by using its device path after calling into this protocol, but this is untested. The firmware might also be so buggy that accessing devices after using this protocol is impossible. It seems prudent to revert this for now until some reliable way is found to initialize console devices without introducing huge boot delays. Any users on firmware where console devices cannot be accessed would have to rely on disabling fastboot. Fixes: #25737, #25846
… devices" This reverts commit b99bf58. It seems that using this protocol on some firmwares to forcibly initialize console devices may break handles (already opened file handles and the device handle itself) that we rely on to access the boot filesystem, making it impossible to load the selected entry. It might be possible to get a new handle by querying for the device handle by using its device path after calling into this protocol, but this is untested. The firmware might also be so buggy that accessing devices after using this protocol is impossible. It seems prudent to revert this for now until some reliable way is found to initialize console devices without introducing huge boot delays. Any users on firmware where console devices cannot be accessed would have to rely on disabling fastboot. Fixes: systemd#25737, systemd#25846 (cherry picked from commit f151abb)
… devices" This reverts commit b99bf58. It seems that using this protocol on some firmwares to forcibly initialize console devices may break handles (already opened file handles and the device handle itself) that we rely on to access the boot filesystem, making it impossible to load the selected entry. It might be possible to get a new handle by querying for the device handle by using its device path after calling into this protocol, but this is untested. The firmware might also be so buggy that accessing devices after using this protocol is impossible. It seems prudent to revert this for now until some reliable way is found to initialize console devices without introducing huge boot delays. Any users on firmware where console devices cannot be accessed would have to rely on disabling fastboot. Fixes: systemd#25737, systemd#25846
systemd version the issue has been seen with
252.3-1
Used distribution
Arch Linux
Linux kernel version used
6.0.12-arch1-1 and 5.15.82-1-lts
CPU architectures issue was seen on
x86_64
Component
bootctl, systemd-boot
Expected behaviour you didn't see
System booting correctly with systemd-boot.
Unexpected behaviour you saw
System hangs immediately after choosing the boot-entry, just showing a black screen with the following message in top left corner in red letters:
Failed to open random seed file: Media changed
Error opening root path: Invalid Parameter
Steps to reproduce the problem
Updating to 252.3-1 WITHOUT running 'bootctl update' afterwards works fine. The system boots without any problems.
So the problem seems really systemd-boot related. Maybe something in 'systemd-bootx64.efi' has changed and my Lenovo E15 Gen 2 doesn't like that.
Additional program output to the terminal or log subsystem illustrating the issue
No response
The text was updated successfully, but these errors were encountered: