Solved Upgrade 14-RELASE @ Root on ZFS, reboot before update boot code and stuck at EFI shell.

epopen

epopen

Hi All

I executed zppol upgrade zpool, but reboot unexpected,🤯
Result: My system stuck at EFI shell, like PR 264453.

I googled to trying to boot to system and update boot code.
but either execute follows command @ EFI Shell
FS0:\> efi\boot\bootx64.efi or FS0:\> efi\freebsd\loader.efi
Got blank screen (Nothing happen)

Can help me rescue?

Thanks very much.
 
I strongly suggest to update boot code(s) BEFORE upgrading pool.

But for now, if you have
  • physical access to the computer,
  • blank (or you can freely erase) memstick,
  • and another computer to download and dd to the memstick,
you should
  • download 14.0-RC4 (or release if already available) memstick.img or mini-memstick.img for your arch,
  • dd it to memstick,
  • boot the unbootable computer with the memstick,
  • escape to live-cd mode from installer,
  • mount problematic EFI partition to (usually) /mnt as msdosfs,
  • and overwrite /boot/loader.efi on the memstick to /mnt/efi/freebsd/loader.efi.
If your computer has been booted using efi/freebsd/loader.efi, it should help.

See RC4 annoucement for where to download.
 
T-Aoki said:
  • mount problematic EFI partition to (usually) /mnt as msdosfs,
  • and overwrite /boot/loader.efi on the memstick to /mnt/efi/freebsd/loader.efi.
If your computer has been booted using efi/freebsd/loader.efi, it should help.
Click to expand...
And if it doesn't boot with efi/freebsd/loader.efi, you should copy /boot/loader.efi to /mnt/efi/boot/bootx64.efi (provided you're on a x64 system).

It's safer to overwrite both files.
 
Emrion said:
It's safer to overwrite both files.
Click to expand...
Correct if FreeBSD is the only OS on the computer.
But if the computer is configured for multiple OS'es and efi/bootx64.efi is used for any of the other OS'es, it can cause the OS unbootable.

And another thing to mention. Maybe already a rare case, but if newer loader.efi does not boot correctly with some reason, it would worth trying to use boot1.efi by copying it as efi/freebsd/loader.efi (or as efi/boot/bootx64.efi for FreeBSD-only computers).
In very early days when loader.efi started supporting to work as efi/boot/bootx64.efi, my ThinkPad T420 (at the moment) hesitated to boot, while boot1.efi was OK. loader.efi started working correctly in later days, but possibly some, maybe old, computers require boot1.efi.
 
And if this disk is not configured for multiple OSes, change efi/freebsd/loader.efi won't likely have any effect on the boot sequence. I have to admit, I don't use multiboot on the same disk. And I rarely use multiboot at all.
 
Emrion said:
And if this disk is not configured for multiple OSes, change efi/freebsd/loader.efi won't likely have any effect on the boot sequence. I have to admit, I don't use multiboot on the same disk. And I rarely use multiboot at all.
Click to expand...
If the only OS is FreeBSD, of course it is safe to overwrite efi/boot/bootx64.efi.

I've never used current installer (bsdinstall) and not having knowledges of its internals, but if it adds and activate an entry for efi/freebsd/loader.efi to EFI boot manager using efibootmgr, and UEFI firmware properly handles the entry, possibly efi/boot/bootx64 is untouched at all.

bsdinstall cannot know if the FreeBSD is the only OS in the system, especially when non-FreeBSD partition and efi/boot/bootx64 already exists.
So the safest side is keeping existing efi/boot/bootx64.efi untouched for bsdinstall.
Overwriting efi/boot/bootx64.efi should be done by admins who know how the computer should be configured.
 
FYI, from <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263488#c0> (2022-04-23):

1700445853098.png


Other bsdinstall-related reports include, in chronological order:

164284 – bsdinstall(8): FreeBSD install assign incorrect dev as bootup disk

bugs.freebsd.org bugs.freebsd.org

243997 – bsdinstall should not format EFI partition

bugs.freebsd.org bugs.freebsd.org

262214 – /boot/efi cannot be mounted during bsdinstall

bugs.freebsd.org bugs.freebsd.org

(At least two of those will benefit from triage.)
 
Hi T-Aoki, Emrion and grahamperrin

The issue fixed.:D
Basically, follows procedure of T-Aoki, overwrite /boot/loader.efi on the memstick to /mnt/efi/freebsd/loader.efi and /mnt/efi/boot/bootx64.efi
Because could not boot when overwrite /mnt/efi/freebsd/loader.efi only.

Next, I tried to update by official procedure but got failed as follows.
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
gpart: /dev/ada0p1: Operation not permitted


even
Code: 
kern.securelevel: -1
No idea whyo_O

I can access disk status as follows
# gpart show
=> 40 468862048 ada0 GPT (224G)
40 532480 1 efi (260M)
532520 2008 - free - (1.0M)
534528 4194304 2 freebsd-swap (2.0G)
4728832 464132096 3 freebsd-zfs (221G)
468860928 1160 - free - (580K)



I am very thankful that all help me quickly and issue fixed.😇
 
epopen said:
gpart bootcode
Click to expand...

Be glad that it failed :)


For the benefit of other readers:

CAUTION​

From <https://www.freebsd.org/releases/13.0R/relnotes/#boot>, with added emphasis:

… To update old ESP partitions, users should stop using the gpart(8) utility. …
Click to expand...

I did give thought to this around a month ago, with regard to draft release notes for 14.0. From <https://reviews.freebsd.org/D42214#963193>:

caution against inappropriate use of gpart(8)
Click to expand...

My then thought was for the caution to appear in the installation information page, which is not yet public at <https://www.freebsd.org/releases/14.0R/> or drafted at <https://github.com/freebsd/freebsd-doc/tree/main/website/content/en/releases/14.0R>.

cperciva@
 
grahamperrin said:

CAUTION​

From <https://www.freebsd.org/releases/13.0R/relnotes/#boot>, with added emphasis:



I did give thought to this around a month ago, with regard to draft release notes for 14.0. From <https://reviews.freebsd.org/D42214#963193>:



My then thought was for the caution to appear in the installation information page, which is not yet public at <https://www.freebsd.org/releases/14.0R/> or drafted at <https://github.com/freebsd/freebsd-doc/tree/main/website/content/en/releases/14.0R>.

cperciva@
Click to expand...
Hi grahamperrin

Thanks your information.
May I missed, I don't find boot code update by manual & upgrade without gpart 😅
Official update procedure update by release announcement possible.:-/
 
epopen said:
Hi T-Aoki, Emrion and grahamperrin

The issue fixed.:D
Basically, follows procedure of T-Aoki, overwrite /boot/loader.efi on the memstick to /mnt/efi/freebsd/loader.efi and /mnt/efi/boot/bootx64.efi
Because could not boot when overwrite /mnt/efi/freebsd/loader.efi only.

Next, I tried to update by official procedure but got failed as follows.
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
gpart: /dev/ada0p1: Operation not permitted


even
Code: 
kern.securelevel: -1
No idea whyo_O

I can access disk status as follows
# gpart show
=> 40 468862048 ada0 GPT (224G)
40 532480 1 efi (260M)
532520 2008 - free - (1.0M)
534528 4194304 2 freebsd-swap (2.0G)
4728832 464132096 3 freebsd-zfs (221G)
468860928 1160 - free - (580K)



I am very thankful that all help me quickly and issue fixed.😇
Click to expand...
Glad to hear you could fix the problem.:)
Failing with `gpart bootcode` method is premature here, because you don't have freebsd-boot partition.
This method is for "Legacy boot", using pmbr and dedicated freebsd-boot partition. Not for UEFI boot. And for UEFI BIOSes, legacy boot depends on CSM of UEFI BIOS, which is not mandatory component.
In ancient days before UEFI BIOSes were available, updating boot codes required `sysctl kern.geom.debugflags=16` to proceed, while the default value is 0. Cannot recall from when, but at a point, this became unneeded if I recall correctly.
 
In the old days of FreeBSD 11 and 12 maybe, the procedure to update the efi bootcode actually used gpart bootcode -p /boot/boot1.efifat .... It was an image of a msdos filesystem containing the loader, so you just have to poke these bytes with this command.

This consideration and warning are now obsolete. Nobody does that since ages.
 
Emrion said:
In the old days of FreeBSD 11 and 12 maybe, the procedure to update the efi bootcode actually used gpart bootcode -p /boot/boot1.efifat .... It was an image of a msdos filesystem containing the loader, so you just have to poke these bytes with this command.

This consideration and warning are now obsolete. Nobody does that since ages.
Click to expand...
Ah, I've completely forgotten about this, as I never tried this, possibly hazardous, way.
If the admin wanted to configure multi-boot environment, this way should be hazardous, as it overwrites whole existing EFI partition.
If I recall correctly, it was because there were some serious problem in FAT32 codes on FreeBSD at the moment and needed FAT16 (if I recall correctly, FAT12 was disallowed by UEFI spec, although many firmwares allowed it) EFI partition.
This method was thrown away once FAT32 on FreeBSD was considered fixed.
 
Hi All

I found other user topic like me as https://forums.freebsd.org/threads/upgrading-zfs-zpool-under-freebsd-14.91076/post-629535
gpart result
Code: 
=>        40  2000409184  nvd0  GPT  (954G)
          40        1024     1  freebsd-boot  (512K)
        1064         984        - free -  (492K)
        2048    67108864     2  freebsd-swap  (32G)
    67110912  1933297664     3  freebsd-zfs  (922G)
  2000408576         648        - free -  (324K)

His boot partition is
Code: 
40        1024     1  freebsd-boot  (512K)
But my boot partition is
Code: 
40     532480     1  efi  (260M)

Is it my failed reason @ # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 possible?
The partition created by new installation procedure @ 13 or 12 -RELEASE, no idea why different compare with other?:rolleyes::rolleyes::rolleyes:
 
epopen said:
Is it my failed reason @ # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 possible?
Click to expand...
It was because you don't have freebsd-boot type partition as partition 1.

Additional note about difference between 2 types of partition size:
In BIOS (CSM) boot, BIOS first reads master boot record (MBR) at the top of the physical drive. MBR includes partition table and initial program loader.
And MBR is constrained with very small size (1 or 2 cluster), which cannot implement codes to access to UFS/ZFS. So MBR for FreeBSD blindly reads whole bunch of freebsd-boot type partition, in so-called "real mode", which supports only 640kbytes of main memory. This is because freebsd-boot partition is at the size of 512 kbytes.

In GPT scheme of partition table, PMBR (pseudo-MBR) is needed not to be destroyed by partitioning softwares supporting old MBR-style partition table. In pmbr, code to understand GPT scheme, find freebsd-boot type partition and load it is impemented with the same limitation in size as MBR.

UEFI firmware, which is configured to prefer UEFI boot, directly accesses GPT partition table and does not use MBR or PMBR and looks for loader in EFI type partition (so called ESP), which is formatted FAT32 (FAT16 is also allowed). ESP can contain multiple loaders for multiple OS'es and theoretically, the maximum size is limited by file system configuration.
Some (maybe most) UEFI firmwares would temporarily writes firmware updates in ESP, so too small size is possibly hazardous.
This is because your EFI partition is large.
 
SirDice said:
They are different ways of booting a system. BIOS boot is the 'old' way, UEFI is the modern way.
...
Click to expand...
T-Aoki said:
It was because you don't have freebsd-boot type partition as partition 1.
...
Click to expand...
Hi SirDic & T-Aoki

I understood.
In my UEFI-GPT booting case, can not update boot code # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
Only update /mnt/efi/boot/bootx64.efi by manual cp

Thanks a lot.
 
You must log in or register to reply here.
Back
Top