Unable to boot rawhide after latest deployment, missing bli.mod file #587
Comments
|
A couple of folks have been reporting this for a few days now in the Silverblue Matrix channel as well. |
|
I managed to boot my system again with some tricks:
After all my grub.cfg of the usb drive looks like this: Now reboot your system, boot from the usb drive, and choose the ostree menu entry. Your system should boot with this. |
Now if somebody can tell me how I can recover my grub somehow from a booted system I'd be really grateful :) |
fails because it can't find
|
|
Interesting. My working F40 Silverblue install does not have a Kinda seems like a switch from BIOS compatibility mode to x64-uefi has happened, maybe that's part of the root cause for this issue? |
|
|
I managed to work around it by installing the missing package in a toolbox and copy the the which unfortunately results in the same missing |
|
I was able to reproduce this in a VM. Content in /boot/efi Content in first deployment Content in second deployment These 2 files do not match any files in either deployments: |
|
It boots again if I replace the two files with the ones from either deployments. This checksum matches the file in So where did this one come from? |
|
Good catch @kanru, can confirm that swapping out those two files makes the system bootable again 👍 |
|
Thanks, @kanru! This resolved the issue for me as well. I hope this only affects Rawhide. I find these bootloader issues quite concerning, because they kind of defeat the purpose of using Silverblue in the first place. (I deployed Silverblue to family members to avoid the situation of getting send an unbootable device, but maybe it is still too experimental and should be marked as such.) |
Rawhide is indeed too experimental for the use case you're describing. It has indeed been marked as such since always, in very strongly worded warnings everywhere, and in fact implied by the name. Not sure what you're expecting here? :) |
|
If it’s only happening on Rawhide it is fine. But grub was broken on normal installations as well, so I guess the boot process is really a weak point, but hopefully this is resolved with bootupd. My thought was that it would be relatively save to rebase to Rawhide, because I could always just rollback to a working deployment, but this was maybe overestimating the power of ostree base distros. My family members a running the stable version of course. |
I'm unaware of any of the reports in this issue, the linked discussion or on Matrix indicating that this is affecting F40 stable releases. Are you seeing something different?
What are you referring to here?
Yes, I think I've run into this mentality a few times now in the Matrix channel as well. I think perhaps the documentation and general stance could (should) be more strongly voiced that Rawhide is not suitable for daily use in any kind of environment that is relied upon. I consider myself a highly chaotic #YOLO hacker man that constantly tests/pushes the limits of my software environment, and I've never ended up with a bricked install, because I don't use Rawhide ;)
👍 I'd strongly recommend you do the same. If you were using Rawhide to access upgraded packages, consider selectively installing the things you care about from Rawhide using the |
No, and that is reassuring.
The outdated grub thing, where you needed to copy a file to make it work.
Seems to be a common misconception. Maybe rpm-ostree could even warn when rebasing to rawhide.
What a nice way to test things. Wasn’t aware of this possibility. Thanks! |
Ah yes, I thought you might be referring to this. I certainly agree with your earlier sentiment about the fragility of bootloaders. There's definitely been a string of unfortunate coincidences this year in that regard, too ;) FWIW, that's an issue with shim, and not GRUB itself. So I would categorize that as a different kind of failure (Secure Boot compatibility, not GRUB) . I also hope that
Yeah, I like that idea :)
You can also make it more permanent if you roll your own image: https://github.com/samcday/workstation-config/blob/41dd33e/Dockerfile#L118-L119 |
|
I can confirm that the fix to boot again is to basically do this:
...no messing with grub configuration files needed. As to get the correct
(You can also find the RPM, download it, use rpm2cpio and such, but I figured the above is easier than hunting down the right file.) Now you should have the correct grubx64.efi, ready to copy to the correct place on your internal storage (the mounted EFI partition, under the |
|
grubx64.efi.txt |
|
For anyone that needs to perform the recovery process, could you backup and share the sha256sum of the not working grubx64.efi file? I'd like to see if they all have the same checksum or all have different ones. Also, does anyone have any idea what rpm-ostree process can affect grub? |
|
@kanru Mine buggy efi 3.5 MB instead of 4.1 MB |
|
Does this bug affect the new branch 41? |
|
Yes, it's reproducible with the latest branched F41. It looks like it's not a corrupted grub, but a incompatible one. After refresh F40 install, the grubx64.efi has the "bad" checksum. It's from grub2-2.06-119.fc40 (grubx64.efi info) After rebase to F41 and reboot - same content - bootable After rebase to F41 and layering syncthing - same content - not bootable |
|
I upgraded to Kinoite 41 and it was broken too, however running With toolbox already manually installed in the live session, I found another alternative solution for acquiring the
After copying the correct
|
Well, to continue my slightly off-topic rant from earlier, right now the So I think you, and likely 99% of the folks in this thread so far, should be rebasing back to F40 and waiting for a proper F41 release :) F41 is still a week and a bit from beta freeze, and not targeted for release until mid October. |
I identified the issue. GRUB 2.12 introduced two incompatible changes in the generated grub.cfg First, the bli module is not available in previous GRUB Second, fwsetup gained a new Both can be fixed by wrapping the command in a test expression. I opened https://bugzilla.redhat.com/show_bug.cgi?id=2305291 |
|
I think you'll only hit this with systems that are still using the dynamic grub config generation; with bootupd we now heavily emphasize static grub configs. But yes, this is also another case on the flip side where rpm-ostree/bootc not updating the bootloader by default can bite folks, xref #120 |
|
I had this too. I did rebase to F41, rebooted without a problem, installed few more packages and got boot broken. |
Could you please specify how to do this? I rebased to 41 to checkout the accent colors, all worked fine, today rebooted and can't restore the system. I got a Fedora 40 live usb running once in it I open terminal, sudo myself, cd to /boot/efi/EFI/fedora/, delete grubx64.efi, then copy in the same directory the "correct one", reboot and nothing - same error. What do I do wrong, how do I do it correctly? Thank you! |
That looks like the Live USB's EFI system partition, try finding your actual system's EFI system partition and mount it at
Edit: added detailed howto |
THANK YOU!!! Back in and rebased to fedora 40 :))) |
|
Thanks @kanru for the investigation here. One option that we have pending bootupd being enabled by default is to patch out those configs for F41 until https://bugzilla.redhat.com/show_bug.cgi?id=2305291 is fixed. |
|
Untested, tentative workaround for this issue: |
New GRUB2 config modules are causing issues on Atomic Desktops systems as the new GRUB2 config get regenerated with new options that are not supported by the currently installed version of GRUB2. The root cause is that we don't (yet) systematically update the bootloader on Atomic Desktops. This is related to: https://gitlab.com/fedora/ostree/sig/-/issues/1 Temporarily remove / modify those config modules from the GRUB2 set of configs used to generate the final GRUB2 config, until we are able to enable bootloader updates by default. See: fedora-silverblue/issue-tracker#587 See: https://bugzilla.redhat.com/show_bug.cgi?id=2305291
|
I've merged the PRs above and they are now available in Rawhide and F41 and this "fixed" (i.e. worked around the issue) as far as I could test. We'll revert those workarounds once we get bootupd doing bootloader updates by default. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Describe the bug
System won't boot anymore, grub displays this for few milliseconds before the system reboots into uefi setup.
To Reproduce
Please describe the steps needed to reproduce the bug:
Expected behavior
The system boots
OS version:
Since I'm not able anymore to boot the system, no idea, but IIRC it was 20240810
Additional context
Related: https://discussion.fedoraproject.org/t/can-t-boot-after-update/128493/6
The text was updated successfully, but these errors were encountered: