upgrade to 15.0 p9: booting freezes with "EFI framebuffer information"

rwv37

rwv37

I posted this yesterday as bug #295463 on Bugzilla, but am now posting here too just in hopes of getting more eyeballs on it (my main server is effectively dead due to this issue). Details can be found in the bug report, but the tl/dr is that after upgrading 15.0-RELEASE from p8 to p9, the machine freezes during the booting process after reporting "EFI framebuffer information", looking very similar (to my largely ignorant eyes) as a previous bug that was resolved in at least 12, 13, and 14 regarding use (or lack thereof) of "the efi_copy_finish function from amd64_tramp".

Again, details can be found in the bug report on Bugzilla. Any help would be greatly appreciated. Thanks in advance.
 
epower53 said:
Do you have a bectl snapshot you can fall back on?
Click to expand...

I... don't think so? Not entirely sure. I don't think I've ever heard of bectl before. Quick look seems like it's something that makes zfs snapshots somehow directly accessible during the boot process? I do have zfs snapshots, but if there's something that would have had to have been specifically done earlier to make them usable in this way now, then no, I almost certainly don't.
 
Are you using pkgbase or did you go the safe route and stick with freebsd-update? If it's the latter, then you should have automatically created boot environments from running freebsd-update. The freebsd bootloader has option 8, which will let you choose to boot into a different boot environment. May as well press 8 and see if there's anything there...

Edit: just read your bug report. You're using freebsd-update, which is good! You already have a boot environment created (assuming you installed on ZFS). Just boot into the latest BE using the boot loader option 8 and you should be back in business.
 
Hmmm, no luck. Or maybe some luck but not sufficient luck :p

I can get into the "Boot Environments" menu, and I do have a whole bunch of snapshots listed there. I selected the p8 snapshot from yesterday, and hit return. Same issue occurred.

I'm not sure if the advisories for the p7 to p8 update (which was pretty recent) said to reboot or not, so I guess it's possible that the problem actually started in p7. I'm a little reluctant to try booting into p7, as I don't yet confidently understand exactly what this "Boot Environments" thing entails, and I'm a bit worried that maybe something else that I changed in the meantime will be missing from the snapshot. I'm going to get some lunch and investigate further before proceeding.
 
OK, I read about what all is included in the "boot environment" snapshots where the zfs layout was decided by the default installation process (which I'm pretty confident I did not override). I then convinced myself (hopefully correctly) that if I manually changed anything in those places in the last few weeks, I would be able to figure out what it was and just do it again. So, I then tried booting to the p7 snapshot.

It boots!

Now to figure out how to roll back to p7 as the default boot environment.

Thanks so much, epower53. This "boot environment" stuff is sooooooooooooo much better than what I've long been used to when something goes wrong during an upgrade - i.e. screwing around with a live CD trying to recover, and often eventually giving up and just wiping the disks and reinstalling the whole shebang.
 
Glad to hear you had a boot environment that helped you recover... BEs are truly great and make it much safer to muck around and break stuff while learning without the harsh consequences of a truly bricked system.
 
You most likely need to update the efi loader. "ls -lR /boot/efi". You will likely see "efi/boot/BOOTx64.efi" and "efi/freebsd/loader.efi" and that they are rather old. Copy "/boot/loader.efi" to both of them (or whichever *.efi is on your machine).
 
bakul, thanks, but those three files (well, I have bootx64.efi rather than BOOTx64.efi) are all bytewise identical. I'm not sure what "rather old" means in this context, but these all have last modification timestamps from early December of last year.

I'm interested in learning more about them, though - I didn't realize that these things need manual maintenance. I'll poke around looking for info, but if anyone knows a good source of it off the top of their head, I'd love to hear it.
 
Oh, wait, I just realized that the files I checked are the ones from the p7 snapshot (i.e. the currently active and non-problematic one). I still have the problematic snapshots, so I'll figure out how to take a look at their versions of these files.
 
On my freebsd 15 release VM:
# uname -r
15.0-RELEASE-p9
# bectl mount 15.0-RELEASE-p7_2026-05-20_155017 /mnt
/mnt
# md5 -r /mnt/boot/loader.efi /boot/efi/efi/*/*.efi /boot/loader.efi
5f4b834e19c220a9afab1c45f08e5641 /mnt/boot/loader.efi
5f4b834e19c220a9afab1c45f08e5641 /boot/efi/efi/boot/bootx64.efi
5f4b834e19c220a9afab1c45f08e5641 /boot/efi/efi/freebsd/loader.efi
5f4b834e19c220a9afab1c45f08e5641 /boot/loader.efi

No difference from -p7 to -p9. Your system freeze cause seems different but do check if the md5 checksum matches.
 
I've had these happen lately, in my case I found a workaround, at the loader prompt hit escape to drop to its shell, type

unload

To unload the kernel, followed by

load /boot/kernel/kernel
load /boot/kernel/zfs.ko
boot

This boots the kernel every single time and mounts my root, drops me to single user mode because other ko's are needed to complete the boot, I reboot from and in 98% of the cases the system reboots normally. This used to happen until about a week ago. Right now my system is booting normally
 
You must log in or register to reply here.
Back
Top