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
 
Sorry, I got kind of sidetracked over the past few days, but I just came back to this now.

When I mount either of the problematic snapshots in /stuff/bobtmpmnt, /stuff/bobtmpmnt/boot/loader.efi is identical to /boot/loader.efi (and therefore to /boot/efi/efi/boot/BOOTx64.efi and /boot/efi/efi/freebsd/loader.efi).

But! /stuff/bobtmpmnt/boot/efi/efi is totally empty. I guess those files got deleted in the upgrade to p8 somehow? I certainly didn't do it knowingly or intentionally.
 
Zare, thanks. A user in the Bugzilla thread did the same thing, and it also worked for them.

Also, both they and another user had luck with another workaround. They removed these lines from their /boot/loader.conf:

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
Click to expand...

I also have those lines in /boot/loader.conf (well, actually /boot/loader.conf.d/cpumicrocode.conf). I have not yet tried this workaround (nor the workaround that you gave), but I intend to do so soon.
 
epower53 said:
Have you tried directly upgrading from your working p7 BE to p9?
Click to expand...

No, I'm still on p7, but I'm about to try that as part of trying the workaround I just mentioned.

Or, actually, now that I think about it a little more, I'm instead first going to try that and copy /boot/loader.conf to the locations in /boot/efi/efi that bakul mentioned (leaving the cpu_microcode stuff in place). If that doesn't work, I'll try the cpu_microcode stuff, and if that doesn't work either, I'll try both.
 
OK, I'm up and running with p9, but... this is pretty wacky (at least when viewed through the lens of my not-all-that-great understanding of all of this stuff):

While booted in BE "default", which was running p7, I fetched and installed p9. Verified (with freebsd-version) that installed and userland were p9, while running was p7. I then rebooted (not having done anything further, such as copying loader.conf around or modifying the cpu microcode stuff). I got the same freezing problem. That was mostly expected, but I wanted to explicitly verify or refute it.

I then booted to BE "15.0-RELEASE-p7_2026-05-24_225844", which had just been created by the freebsd-update that I did. My intent was to use it to check if the copies of loader.conf had in fact been removed (as at least kind of expected), and, if so, copy them back in. But I couldn't get that far... because I got the same boot freeze using "15.0-RELEASE-p7_2026-05-24_225844".

That was totally unexpected (by me, at least). I had expected "15.0-RELEASE-p7_2026-05-24_225844" to be an exact duplicate of "default" from immediately before having done the freebsd-update. And that "default" BE had rebooted just fine a few days ago, and I'd been using it ever since. Plus, as mentioned earlier in this thread, I had verified that the copies of loader.conf were present in it, and that they were in fact bytewise equal to /boot/loader.conf. So, I had fully expected that they would still be present in "15.0-RELEASE-p7_2026-05-24_225844" even if today's freebsd-update had removed them from "default".

Note before continuing: To be explicit, all wackiness is above this point; everything below went as I was expecting or at least largely expecting.

So, I rebooted again, this time to BE "15.0-RELEASE-p6_2026-04-29_193148", hoping I could use that one to fix "default".

The reboot worked, and I saw that the copies of loader.conf had in fact been deleted from "default". I copied the version of loader.conf from "default" to its other expected locations within "default".

Rebooted again, into "default". Freeze again. Largely but not entirely expected, as I intentionally had not removed the cpu microcode stuff that users in the Bugzilla thread had found problematic.

Rebooted again, into the p6 BE. Removed the cpu microcode stuff from "default" (to be explicit, only those two lines mentioned in the earlier comment; there was also cpuctl_load="YES", which I did not remove).

Rebooted again, into "default". No freeze. Verified that p9 is everywhere (installed, running, userland).
 
How is your physical drive partitioned? The reason I ask is that I've never encountered a snapshot that fails to capture metadata pointing to specific files.
 
rwv37 said:
Zare, thanks. A user in the Bugzilla thread did the same thing, and it also worked for them.

Also, both they and another user had luck with another workaround. They removed these lines from their /boot/loader.conf:



I also have those lines in /boot/loader.conf (well, actually /boot/loader.conf.d/cpumicrocode.conf). I have not yet tried this workaround (nor the workaround that you gave), but I intend to do so soon.
Click to expand...

Indeed, it does seem like I've stopped having troubles about 10 days ago...

Code: 
-rw-r--r--  1 root wheel 17104896 May 14 04:12 /boot/firmware/intel-ucode.bin
 
epower53 said:
How is your physical drive partitioned? The reason I ask is that I've never encountered a snapshot that fails to capture metadata pointing to specific files.
Click to expand...
First, I want to say that I'm not 100% sure that I'm giving you all of the information you're looking for here, so if there's something missing from the following, please let me know.

There are two physical drives, ada8 and ada9, that are in a ZFS mirror. They're the same make and model, and are identical in terms of gpart:

[163948 root@iron 1;~]# gpart show ada8
=> 40 3907029088 ada8 GPT (1.8T)
40 532480 1 efi (260M)
532520 2008 - free - (1.0M)
534528 268435456 2 freebsd-swap (128G)
268969984 3638059008 3 freebsd-zfs (1.7T)
3907028992 136 - free - (68K)

[163956 root@iron 1;~]# gpart show ada9
=> 40 3907029088 ada9 GPT (1.8T)
40 532480 1 efi (260M)
532520 2008 - free - (1.0M)
534528 268435456 2 freebsd-swap (128G)
268969984 3638059008 3 freebsd-zfs (1.7T)
3907028992 136 - free - (68K)
Click to expand...

The freebsd-zfs uhhhhh... partitions? are encrypted with GELI:

[164754 root@iron 1;~]# ls -l /dev/ada8*
crw-r----- 1 root operator 0xda May 24 23:37 /dev/ada8
crw-r----- 1 root operator 0xed May 24 23:37 /dev/ada8p1
crw-r----- 1 root operator 0xef May 24 23:37 /dev/ada8p2
crw-r----- 1 root operator 0xf1 May 24 23:37 /dev/ada8p3
crw-r----- 1 root operator 0x106 May 24 23:37 /dev/ada8p3.eli
[164817 root@iron 1;~]# ls -l /dev/ada9*
crw-r----- 1 root operator 0xdc May 24 23:37 /dev/ada9
crw-r----- 1 root operator 0xf3 May 24 23:37 /dev/ada9p1
crw-r----- 1 root operator 0xf5 May 24 23:37 /dev/ada9p2
crw-r----- 1 root operator 0xf7 May 24 23:37 /dev/ada9p3
crw-r----- 1 root operator 0x10b May 24 23:37 /dev/ada9p3.eli
Click to expand...

And mirrored as ZFS pool zos:

[165031 root@iron 1;~]# zpool status zos
pool: zos
state: ONLINE
scan: scrub repaired 0B in 00:37:36 with 0 errors on Tue May 5 08:47:36 2026
config:

NAME STATE READ WRITE CKSUM
zos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada8p3.eli ONLINE 0 0 0
ada9p3.eli ONLINE 0 0 0

errors: No known data errors
Click to expand...

That zos pool is where all the OS-related stuff is:

[165217 root@iron 1;~]# zfs list | rg zos
zos 792G 882G 96K /zos
zos/ROOT 768G 882G 96K none
zos/ROOT/14.0-RELEASE-p10_2024-09-08_215614 8K 882G 14.6G /
zos/ROOT/14.0-RELEASE-p4_2024-02-14_160451 8K 882G 4.30G /
zos/ROOT/14.0-RELEASE-p5_2024-04-02_145742 8K 882G 4.43G /

(... a bunch more bectl-created ones omitted for brevity, and...)

zos/ROOT/default 753G 882G 111G /
zos/home 10.2G 882G 1.02G /home
zos/tmp 562M 882G 244K /tmp
zos/usr 8.39G 882G 96K /usr
zos/usr/ports 6.70G 882G 1.06G /usr/ports
zos/usr/src 1.69G 882G 983M /usr/src
zos/var 3.64G 882G 96K /var
zos/var/audit 96K 882G 96K /var/audit
zos/var/crash 96K 882G 96K /var/crash
zos/var/log 3.64G 882G 172M /var/log
zos/var/mail 2.85M 882G 436K /var/mail
zos/var/tmp 1.02M 882G 96K /var/tmp
Click to expand...

There's another pool, zdata, on a different set of drives, but everything on it is mounted into /stuff (or subdirectories thereof), so I believe there's no weird thing going on like "Oh, /boot is on zos, but /boot/efi is on zdata".

[170657 root@iron 1;~]# zfs list | rg "^zdata[/ ]" | wc
60 300 7565
[171038 root@iron 1;~]# zfs list | rg "^zdata[/ ]" | awk '{print $5}' | cut -c1-7 | sort | uniq -c
1 /stuff
59 /stuff/
Click to expand...

Finally, there's yet another physical drive, but the only thing FreeBSD knows about it (as far as I know) is that it exists.
 
You must log in or register to reply here.
Back
Top