Re: unable to boot latest 14-stable

On 10/11/2023 05:19, void wrote:
> Do you think the following might allow the system to boot:
>
> 1. get 14-stable beta5 and on another freebsd box, mount its msdos 
> partition
> with mdconfig -f
>
> 2. unplug the usb3 disk from the rpi, plug it into the freebsd box, do 
> the same as [1]
>
> 3. copy the contents of [1] into [2]
>
> I'm worried the process might clobber something GELI needs though, 
> rendering the zpool/disk
> permanently inaccessible.

Get access to the installed partition (mount it on something else, etc.) 
and look in here:

[karl@NewFS ~]$ ls -al /boot/*efi*
-r-xr-xr-x  1 root  wheel  113664 Jun 21 12:53 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Aug 10  2022 /boot/boot1.efifat
-r--r--r--  1 root  wheel    1525 Jun 21 12:53 /boot/efi.4th
-r-xr-xr-x  1 root  wheel  109568 Jun 21 12:53 /boot/gptboot.efi
-r--r--r--  1 root  wheel  819200 Aug 10  2022 /boot/gptboot.efifat
-r-xr-xr-x  2 root  wheel  907264 Jun 21 12:53 /boot/loader.efi
-r--r--r--  1 root  wheel   13653 Jun 21 12:53 /boot/loader.help.efi
-r-xr-xr-x  1 root  wheel  820224 Jun 21 12:53 /boot/loader_4th.efi
-r-xr-xr-x  2 root  wheel  907264 Jun 21 12:53 /boot/loader_lua.efi
-r-xr-xr-x  1 root  wheel  761344 Jun 21 12:53 /boot/loader_simp.efi

The file you want is /boot/loader.efi (which is a hard link to 
loader_lua.efi) - that goes in the EFI partition on the boot device.  
Note this:

[root@NewFS /home/karl]# file /boot/loader_lua.efi
/boot/loader_lua.efi: PE32+ executable (EFI application) x86-64, for MS 
Windows

For ARM it will obviously not be "x86-64", but you will note that while 
this is on the FreeBSD filesystem it is NOT a FreeBSD executable -- it 
is an EFI executable, which is what needs to be there, and it was 
created when the kernel and running environment was and thus, assuming 
that's the environment that did the "zpool upgrade", has the correct 
bits in it to be able to handle it.

Note that you cannot use the x86 loader on an ARM box; you need this 
from the same architecture device.  You already have it if the device 
has root on an external disk (assuming that is the environment that did 
the zpool upgrade) so doing it off that disk should work.  This is what 
an x86 EFI partition looks like:

[root@NewFS /home/karl]# ls -alR /mnt
total 33
drwxr-xr-x   1 root  wheel  4096 Dec 31  1979 .
drwxr-xr-x  37 root  wheel    44 Jun 21 12:56 ..
drwxr-xr-x   1 root  wheel  4096 Feb 20  2021 EFI

/mnt/EFI:
total 24
drwxr-xr-x  1 root  wheel  4096 Feb 20  2021 .
drwxr-xr-x  1 root  wheel  4096 Dec 31  1979 ..
drwxr-xr-x  1 root  wheel  4096 Feb 20  2021 BOOT

/mnt/EFI/BOOT:
total 2728
drwxr-xr-x  1 root  wheel    4096 Feb 20  2021 .
drwxr-xr-x  1 root  wheel    4096 Feb 20  2021 ..
-rwxr-xr-x  1 root  wheel  893952 Nov 10  2022 BOOTX64.EFI
-rwxr-xr-x  1 root  wheel  489984 Oct  9  2022 OLDBOOTX64.EFI

It will NOT be called BOOTX64.EFI but it WILL be in that partition under 
EFI/BOOT; whatever the name is, that's what you copy the loader_lua.efi 
to.  Note that mine is currently "old" but still fine because I've 
upgraded under a minor version (which didn't change the zpool format); 
this box is 13.x and when it goes to 14 I will have to update all the 
EFI partitions (that's a mirror, so there are two) or it won't boot once 
the pools are upgraded.

That's what the EFI system will look for and attempt to load and execute.

I have been bit by this in the land before EFI time with "legacy" 
bootcode (some years ago) as the upgrade procedure does not modify the 
bootcode.  You're "safe" doing that PROVIDED you do not do a "zpool 
upgrade"; if you DO, and haven't fixed the bootcode first, you're 
screwed as you had happen.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/