Solved Impossible to boot after upgrade to FreeBSD 13.0-RELASE

I'm stuck at boot after upgrading from FreeBSD 12.2-RELEASE using ZFS and I guess the problem is the new efi bootloader; so I tried to copy it from a Live CD, as explained in the release notes, and here:


but apparently I have not enough space on /dev/ada0p1/

I've also tried to use the efibootmgr(8) utility, again, as suggested in the release notes, but I get this error:

efibootmgr: Cannot translate unix loader path

Can someone please guide me towards a solution? Thanks a lot!
 
I ran into the same problem and fixed it using a dangerous process. May be someone will show a better way but here is my method:

You have to resize the efi partition. If you used the defaults when installing freebsd on your machines, chances are, ada0p2 is of type freebsd-boot and ada0p3 is of type freebsd-swap. Save the entire contents of ada0p2, delete the p2 partition using gpart, shrink the p3 swap partition -- I think you have to delete it and then add it back, using the right offset, expand ada0p1 to about 40MB, add back p2, using the right offset.

This is all highly risky so practice using a memory device (truncate -s <size of your zroot disk) practice; mdconfig -a -t vnode -f disk) and partition /dev/md0 (or whatever) using exactly the same setup as your current disk. And *then* use the steps above. You can try this until you get it right and then try it on the real disk.

Again, beware this is highly risky. If you screw up I can't help you. Better make sure you have a backup of the filesystem first!
 
Yes, I used the defaults when installing and actually, the ada0p1 efi partition, following gpart show, is 200M.

But when I mount it as a msdosfs it shrinks to less than 1M, not enough to copy the loader.efi file there.

So, to resume, I have:

ada0 GPT (932G) 1 efi (200M) 2 freebsd-boot (512K) - free - (492K) 3 freebsd-swap (2.0G) 4 freebsd-zfs (929G) - free - (708K)

Before eventually trying what you suggested, I would like to understand what I did wrong!
 
Resizing the ESP should only be necessary if it is actually the partition that is too small, so before even thinking about such drastic measures you should check the current size of the ESP using gpart show. In most cases the lack of space is caused by having used the /boot/boot1.efifat filesystem image previously. That file was an image of a FAT filesystem just big enough to hold it's contents, so if you try to write anything beyond that, you will get an error. If that is the case, as evidenced by the ESP being big enough, the solution is to create a new FAT filesystem on the ESP (i.e. using newfs_msdos(8)), mount the ESP, create the directory structure (EFI/Boot) and finally copy /boot/loader.efi to the ESP as EFI/Boot/bootx64.efi.
 
Yes, I used the defaults when installing and actually, the ada0p1 efi partition, following gpart show, is 200M.

But when I mount it as a msdosfs it shrinks to less than 1M, not enough to copy the loader.efi file there.

So, to resume, I have:

ada0 GPT (932G) 1 efi (200M) 2 freebsd-boot (512K) - free - (492K) 3 freebsd-swap (2.0G) 4 freebsd-zfs (929G) - free - (708K)

Before eventually trying what you suggested, I would like to understand what I did wrong!
Better! newfs_msdos as Mickey says. I copied /boot/loader.efi to EFI/freebsd/loader.efi.
 
mickey, you saved my day, my week I would say! My computer is booting again and I can ssh into it.

So, this is what I did, following your message:

newfs_msdos ada0p1 mount -t msdosfs /dev/ada0p1 /tmp cd /tmp mkdir -p EFI/Boot cd /EFI/Boot cp /boot/loader.efi . mv loader.efi bootx64.efi

But (I hardly have to courage to confess this) in a first time I wrongly did:

newfs_msdos ada0p2

Wiping away the freebsd-boot partition, I suppose. Is there something I should do to remedy my stupidity?
 
Wiping away the freebsd-boot partition, I suppose. Is there something I should do to remedy my stupidity?
The freebsd-boot partition is only needed for "legacy" (non-UEFI) boot. If you might ever need this, you can install legacy boot code with

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0

This will overwrite the freebsd-boot partition (at index 2) with /boot/gptzfsboot.
 
Thanks, I won't touch that partition again, for the moment, since I'm using UEFI.

So what I did with your help is the normal procedure to update the boot loader when upgrading to FreeBSD 13.0-RELEASE, am I right, as explained in the Boot Loader Changes section of the release notes?

Again, your help has been precious!
 
Thanks, I won't touch that partition again, for the moment, since I'm using UEFI.
You should update both boot loaders to ensure your system is capable of booting in UEFI and BIOS mode. As long as you dont get the index wrong there is nothing to worry about. However next time you have to temporarily mount a filesystem, such as your ESP, please use /mnt for it instead of /tmp, which could have unforeseen consequences.
 
You should update both boot loaders to ensure your system is capable of booting in UEFI and BIOS mode.
If you have both kinds of bootcode installed anyways, I agree. OTOH, my machines only have either UEFI or legacy bootcode cause it's somewhat unlikely to change the boot method on the same machine ;)
However next time you have to temporarily mount a filesystem, such as your ESP, please use /mnt for it instead of /tmp, which could have unforeseen consequences.
Definitely a good point. Never mount over /tmp. And for the ESP, a dedicated mountpoint should exist at /boot/efi (although it's optional to use it of course).
 
If you have both kinds of bootcode installed anyways, I agree. OTOH, my machines only have either UEFI or legacy bootcode cause it's somewhat unlikely to change the boot method on the same machine ;)
That could easily happen when upgrading a non UEFI mainboard to a new UEFI capable one. 🥶
Definitely a good point. And for the ESP, a dedicated mountpoint should exist at /boot/efi (although it's optional to use it of course).
I don't know who came up with mounting the ESP on /boot/efi but if you think about it, that gives /boot/efi/efi/boot/bootx64.efi. Oh well.
 
Definitely a good point. Never mount over /tmp. And for the ESP, a dedicated mountpoint should exist at /boot/efi (although it's optional to use it of course).
I used /tmp because I had found the mention, here, on the forum, that /mnt could be read-only; but actually I didn't check.
 
I used /tmp because I had found the mention, here, on the forum, that /mnt could be read-only; but actually I didn't check.
This sounds pretty weird. /mnt is just a general-purpose mountpoint for temporary mounts. Some also use it as a directory to contain other mountpoints for things that don't have a dedicated place, but the normal usage is (as root) to temporarily mount something there.

The problem with /tmp is that any program expects it to be writable for temporary files. Mounting something over /tmp might lead to one of two things: If the mounted filesystem is writable, temporary files might end up there. If it isn't, programs needing to write a temporary file might fail.

I don't know who came up with mounting the ESP on /boot/efi but if you think about it, that gives /boot/efi/efi/boot/bootx64.efi. Oh well.
Symmetric things are beautiful 🤡
 
This is where I found the idea of using /tmp instead of /mnt:
 
Back
Top