Solved How to proper update bootcode in 14.1 (EFI+ZFSBOOT+Full disk encryption)?

BaronBS

BaronBS

Hello forum.

So, a few weeks ago I updated my Latitude5400 from 13.3 to 14.1. A couple of days later I discovered (by running # zpool status) that my zroot pool had a upgrade available. Like a ignorant f..ker I just ran # zpool upgrade zroot expecting that would be the only thing I needed to do. After a couple of "power downs and power ups" later the system gets unbootable (IDK why it booted a couple of times before stoped).

Doing some research I found out that I should have updated the bootcode. So my next step was to boot a live system and try to update the bootcode from there. So reading the handbook I found this:
1723036247889.png


My setup is EFI+ZFS (on root with encryption), so I tried the second command without any luck. My system don't have /boot/boot1.efifat.
1723036814034.png


Went back to the Cyberspace to look for more clues, and found this comment:
Cath O'Deray said:
For the future: <https://www.freebsd.org/releases/13.0R/relnotes/#boot> the note about not using gpart(8).
Click to expand...
That took me to this part of the 13.0-release notes:

1723037648840.png

"Ok, now I have a proper path to follow" the innocent old me. listing my efi boot entries with # efibootmgr -v I notice that the FBSD boot entry was there, BUT it was in the "Unreferenced Variables" section and it had a "(null)" field in the end, something like this (Simulation of the output because I don't have any image):
Code: 
Boot to FW : false
BootCurrent: 0003
Timeout    : 0 seconds
BootOrder  : 0003, 0004
+Boot0003* Onboard NIC(IPV4) PciRoot(0x0)/Pci(0x1f,0x6)/MAC(3448ed433a7f,0x0)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)
                            VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,490050003400200049006e00740065006c002800520029002000450074006800650072006e0065007400200043006f006e006e0065006300740069006f006e002000280034002900200049003200310039002d004c004d000000)
 Boot0004* Onboard NIC(IPV6) PciRoot(0x0)/Pci(0x1f,0x6)/MAC(3448ed433a7f,0x0)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000,0x0,Static,0000:0000:0000:0000:0000:0000:0000:0000,0x40,0000:0000:0000:0000:0000:0000:0000:0000)
                            VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,490050003600200049006e00740065006c002800520029002000450074006800650072006e0065007400200043006f006e006e0065006300740069006f006e002000280034002900200049003200310039002d004c004d000000)


Unreferenced Variables:
Boot0006* FreeBSD HD(1,GPT,33e94826-4e83-11ef-ad1b-3448ed433a7f,0x28,0x82000)/File(\efi\freebsd\loader.efi)
                      gpt/efiboot0:/efi/freebsd/loader.efi /boot/efi//efi/freebsd/loader.efi (null)

I tried to activate the boot entry using almost every flag combination in efibootmgr(8) without any luck, every time I rebooted, the boot entry was gone in the boot menu.

At this point I just wanted my system back no matter what. So in the live system, I mounted my home pool, made a new snapshot, sent a differential diff to my backup server and reinstalled FBSD using the 14.1 ISO. Then imported my last BE and home snapshots from my backups.

After a few minutes I had my system back and fully upgraded. But I still don't know how to upgrade the bootcode. And now it is the backup server turn to be upgraded. I already upgraded from 13.3 to 14.0 and from 14.0 to 14.1. System and ports are complete up to date. The only thing missing is the bootcode and zpool upgrade.

Can someone ELI5 how it is the correct way to do it, please?
 
Mount the efi partition, it's probably already in fstab and getting mounted on /boot/efi. But if you have multiple disks you will have to mount each individual disk separately. Then just copy /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi.
 
SirDice said:
Mount the efi partition, it's probably already in fstab and getting mounted on /boot/efi. But if you have multiple disks you will have to mount each individual disk separately. Then just copy /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi.
Click to expand...
But this requires booting from a live medium, in this case; FreeBSD 14.1, right?
 
nxjoseph said:
But this requires booting from a live medium, in this case; FreeBSD 14.1, right?
Click to expand...
No, it doesn't. You can do this on the running system. Preferably before or right after you ran the zpool upgrade command to upgrade the pools. Or update the boot code right after an update/upgrade of the OS.

You would only need to boot from a live medium if you screwed up and the system doesn't boot at all. Then the install media should have the same (or newer) version as your system.
 
SirDice said:
Mount the efi partition, it's probably already in fstab and getting mounted on /boot/efi. But if you have multiple disks you will have to mount each individual disk separately. Then just copy /boot/loader.efi to /boot/efi/efi/freebsd/loader.efi.
Click to expand...
SirDice said:
No, it doesn't. You can do this on the running system. Preferably before or right after you ran the zpool upgrade command to upgrade the pools. Or update the boot code right after an update/upgrade of the OS.

You would only need to boot from a live medium if you screwed up and the system doesn't boot at all. Then the install media should have the same (or newer) version as your system.
Click to expand...
So, the upgrade process from 13.3 -> 14.1 should be:
Code: 
$ doas freebsd-update fetch install
$ doas shutdown -r now
$ doas freebsd-update -r 14.0-RELEASE upgrade
$ doas freebsd-update install
$ doas shutdown -r now
$ doas freebsd-update install
$ doas pkg-static upgrade -f
$ doas freebsd-update install
$ doas shutdown -r now
$ doas freebsd-update install # (just to see if it need something else, if so, reboot and move on, if not just move on)
$ doas freebsd-update fetch install # (just to see if it need something else, if so, reboot and move on, if not just move on)
$ doas freebsd-update -r 14.1-RELEASE upgrade
$ doas freebsd-update install
$ doas shutdown -r now
$ doas freebsd-update install
$ doas pkg-static upgrade -f
$ doas freebsd-update install
$ doas cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
$ doas zpool upgrade zroot
$ doas shutdown -r now
$ doas freebsd-update install # (just to see if it need something else, if so, reboot and move on, if not just move on)
$ doas freebsd-update fetch install # (just to see if it need something else, if so, reboot and move on, if not just move on)
Is that it?

Emrion said:
Try my tool: https://github.com/Emrion/uploaders
Click to expand...
Nice tool mate, even nicer readme ;-)
 
BaronBS said:
So, the upgrade process from 13.3 -> 14.1 should be:
Code: 
$ doas freebsd-update fetch install
$ doas shutdown -r now
$ doas freebsd-update -r 14.0-RELEASE upgrade
$ doas freebsd-update install
$ doas shutdown -r now
$ doas freebsd-update install
$ doas pkg-static upgrade -f
$ doas freebsd-update install
$ doas shutdown -r now
$ doas freebsd-update install # (just to see if it need something else, if so, reboot and move on, if not just move on)
$ doas freebsd-update fetch install # (just to see if it need something else, if so, reboot and move on, if not just move on)
$ doas freebsd-update -r 14.1-RELEASE upgrade
$ doas freebsd-update install
$ doas shutdown -r now
$ doas freebsd-update install
$ doas pkg-static upgrade -f
$ doas freebsd-update install
$ doas cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
$ doas zpool upgrade zroot
$ doas shutdown -r now
$ doas freebsd-update install # (just to see if it need something else, if so, reboot and move on, if not just move on)
$ doas freebsd-update fetch install # (just to see if it need something else, if so, reboot and move on, if not just move on)
Is that it?


Nice tool mate, even nicer readme ;-)
Click to expand...
Apparently, it worked. Gonna leave this thread open for a couple of days just in case stop booting after a while, just like with my Latitude5400.
 
Seems a bit excessive in the install+reboot repetitive steps; doesn't it say if an additional run after reboot should be performed? Anyone know of a document saying 14.0 is "needed" before the leap to 14.1+? Doubt it matters but pkg in place of pkg-static should be fine too if things aren't broken. If you use kernel modules from ports, you should disable them from being loaded when rebooting into a newer kernel with them outdated and not reenable them until after updating them.
 
Mirror176 said:
Seems a bit excessive in the install+reboot repetitive steps
Click to expand...
Well, the handbook say that you would need to do 2 or 3, I do 3 just to be sure.
1723148263151.png

Mirror176 said:
doesn't it say if an additional run after reboot should be performed?
Click to expand...
Yes, it does:
1723148384838.png


Mirror176 said:
Anyone know of a document saying 14.0 is "needed" before the leap to 14.1+?
Click to expand...
No, I don't. But I don't think that could hurt the system, if it is in fact not necessary.

Mirror176 said:
Doubt it matters but pkg in place of pkg-static should be fine too if things aren't broken.
Click to expand...
Yes, but only between minor versions, between major versions it is necessary because of the ABI change. As described in the handbook:
1723148695458.png


I do it after a minor upgrade too because it make me fell better. I also don't that could hurt the system.

Please correct me if I'm wrong.
 
BaronBS said:
So, the upgrade process from 13.3 -> 14.1 should be:
Rich (BB code): 
[...]
$ doas pkg-static upgrade -f
$ doas freebsd-update install
$ doas cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
$ doas zpool upgrade zroot
$ doas shutdown -r now
Click to expand...
BaronBS said:
Is that it?
Click to expand...
zpool upgrade could well result in burning your bridges ...

ZFS has the very nice feature of a Boot Environment (BE). Currently they are standard created automatically (taking an active control and creating them yourself puts you in the driver seat, allowing your own naming scheme).

As BEs create a very easy and comfortable fallback option, I consider it wise to retain that option while not having booted into my final configuration and perhaps confirming that the final base-install upgrade works 100% satisfactory especially in combination with all the package updates.

Doing a zpool upgrade will block a return to a previous state via a BE when incompatibilities in feature flags between your updated ZFS (root) pool and the a previous version related to the relevant previous OS: see FreeBSD / ZFS Upgrade Best Practice Question.

IF you are certain that you need new feature flags immediately, you can upgrade your ZFS pools at the cost of most likely (EDIT:*) not being able to boot from previous BEs.

___
* EDIT: cutting off access to previous BEs. As BEs are basically bootable versions of cloned snaphots, the BEs data are still accessable, but their ability to be booted from is in question.
 
Erichans said:
zpool upgrade could well result in burning your bridges ...

ZFS has the very nice feature of a Boot Environment (BE). Currently they are standard created automatically (taking an active control and creating them yourself puts you in the driver seat, allowing your own naming scheme).

As BEs create a very easy and comfortable fallback option, I consider it wise to retain that option while not having booted into my final configuration and perhaps confirming that the final base-install upgrade works 100% satisfactory especially in combination with all the package updates.

Doing a zpool upgrade will block a return to a previous state via a BE when incompatibilities in feature flags between your updated ZFS (root) pool and the a previous version related to the relevant previous OS: see FreeBSD / ZFS Upgrade Best Practice Question.

IF you are certain that you need new feature flags immediately, you can upgrade your ZFS pools at the cost of most likely cutting off access to previous BEs.
Click to expand...
I kind of expected that since the loader.efi is different between BE's. But it is good that it is registered here, thanks.
 
BaronBS said:
I kind of expected that since the loader.efi is different between BE's. But it is good that it is registered here, thanks.
Click to expand...
/boot/loader.efi should be in BEs, but loader.efi in ESP is not, unfortunately.
Unless you are kicking /boot/loader.efi via boot1.efi or gptboot.efi (possibly renamed as BOOT${ARCH}.efi), loader.efi in ESP kicks kernel directly. Note that ${ARCH} here would be x64 for amd64.
 
T-Aoki said:
/boot/loader.efi should be in BEs, but loader.efi in ESP is not, unfortunately.
Unless you are kicking /boot/loader.efi via boot1.efi or gptboot.efi (possibly renamed as BOOT${ARCH}.efi), loader.efi in ESP kicks kernel directly. Note that ${ARCH} here would be x64 for amd64.
Click to expand...
So, could a loader.efi from 14.0 boot a BE from 13.3?
 
Erichans said:
No, but in leaping over 14.0 directly to 14.1-RELEASE, it is necessary (at a minimum for ZFS) that you read and apply the update of the loader as mentioned in FreeBSD 14.0-RELEASE Release Notes, and better all relevant items referenced in FreeBSD 14.0 Release InformationInformation—in addtion to those of 14.1-RELEASE.
Click to expand...
That needs to be done before upgrading/creating any newer zfs pools (assuming you don't limit features/set compatibility) you plan to boot from. I don't recall any compatibility requiring it for amd64 other than the pools but I'd recommend it be upgraded.
BaronBS said:
So, could a loader.efi from 14.0 boot a BE from 13.3?
Click to expand...
Yes. The newer loader understands the newer ZFS features but does not require them so will work with older pools too. Other changes I recall are backward compatible improvements. Things that would be removals were stated to be broken anyway (i386) or other code cleanup of unused things.

Any change is a chance for bugs/problems so testing is a good idea and it reminds me that I view it a little odd that there isn't usually talk of renaming the old boot loader and placing a newer one so both could be selected from UEFI boot menus.
 
BaronBS said:
So, could a loader.efi from 14.0 boot a BE from 13.3?
Click to expand...
For UEFI loaders, yes. For BIOS loaders (off-topic here, though), maybe.

UEFI loaders can be expanded more, so when new features which are NOT readonly-compatible are added and enabled by default (to new or upgraded pools), the features can be added if someone can take care of it.
Usually, new features become default when UEFI loaders get supprorts for it.

For BIOS loaders, the sizes of boot codes mandatory to kick loader simultaneously is quite, quite limited that adding something new almost mandates to drop any of existing features. So ZFS-on-Root installations are strongly discouraged to use BIOS boot. bsdimp should know much deeper than me.
 
You must log in or register to reply here.
Back
Top