Utility that tries to figure how to update the FreeBSD loaders

[T-Aoki]

loaders-update is intended for simple systems and, in some ways, inexperienced users.

Agreed.

Note that, as a fallback, it's simpler to keep an USB key with an appropriate version of FreeBSD inside. I mean if you have a physical access to the machine.

That said, I never experienced a boot problem after updating the loaders.

Unfortunately, I've experienced the situation before.
With the broken boot1.efi (at the moment, loader.efi must be kicked from boot1.efi), even when booted from USB memstick, FreeBSD which was in the first recognized hard drive by firmware was booted, thus cannot repair using memstick on UEFI boot.

But fortunately, at the moment, I had freebsd-boot partition for legacy boot (just using it when I started to test UEFI boot) and I could rescue myself to be able to boot with disabling UEFI boot on firmware config.

The top of thread on freebsd-current ML reporting the issue.

Review of the fix was D5108.
As I didn't registered (as I'm not sure I, not a FreeBSD committer is allowed to register there or not) at the moment, my reports are all via email (on or off list).

 

[miconof]

loaders-update is intended for simple systems and, in some ways, inexperienced users.

yes and no

It's really fast for an experienced users to forget a boot loader update after a zpool upgrade.

This check process part should be included in documentation and base script of freebsd-update.

Maybe it's already in.

But I my case, I miss the boot loader upgrade one or two time after a pool upgrade and it's not a fun case.

 

[Emrion]

yes and no

It's really fast for an experienced users to forget a boot loader update after a zpool upgrade.

This check process part should be included in documentation and base script of freebsd-update.

Maybe it's already in.

But I my case, I miss the boot loader upgrade one or two time after a pool upgrade and it's not a fun case.

True. I don't consider myself as inexperienced and I use this software on all my machines. It's quicker and avoid typing errors.

At the base, I wrote this because of the recurrent problems/questions/disasters that we get here from people, often new users, but not only.

Of course, I was bitten as well by this, but in an uncommon way: https://forums.freebsd.org/threads/why-its-important-to-upgrade-efi-boot-bootx64-efi.79503

I agree, this should be part of freebsd-update with all the precautions needed by this delicate operation. I ported this software also in this idea, to attract the attention of the base committers.

From my point of view, it's one of the two main problems in using/installing/discovering FreeBSD and certainly a reason why some people fled this OS. The other is the kernel modules that remain unusable with the package system during the first three months of a minor release. This is incomprehensible to a standard user. On that point, I have no solution so far, but I'm thinking about it.

 

[T-Aoki]

It's really fast for an experienced users to forget a boot loader update after a zpool upgrade.

It should be BEFORE zpool upgrade.

It would be best (but not sure it could be accepted upstream) if zpool upgrade forcibly invoke boot code update if any of the specified pool have bootfs and error out without upgrading if it doesn't finished successfully.

 

[Emrion]

It should be BEFORE zpool upgrade.

I ain't sure that it the only thing that need upgraded bootcodes. See: https://forums.freebsd.org/threads/why-its-important-to-upgrade-efi-boot-bootx64-efi.79503

 

[T-Aoki]

Well, upgrading boot code AFTER upgrading pool could be hazardous.

Imagine if the computer crashes just after upgrading the pool is finished, but before updating boot codes which support the newly enabled features with some reason (sudden AC line failures etc.).
It can easily cause unbootable computer.

And this also applies if you manually enable/activate any of the features that currently installed boot code doesn't support.
This case needs some more investigations before doing. You need to look for newer releases/stables and main (aka current) which its boot codes support the feature. You need to update your boot code of which you found.

Note that read compatible features are safe. Only read incompatible features matter.

 

[Emrion]

I was saying that I think the bootcodes update should be done at system upgrade time (during freebsd-update). Because some problems may arise even if you didn't upgrade the pool as in the link I posted. So, it's before upgrading any pool and even if you don't upgrade your pool(s).

 

[T-Aoki]

I was saying that I think the bootcodes update should be done at system upgrade time (during freebsd-update).

100% agreed for binary upgrade (freebsd-update) users.
But not all users do binary upgrade but source upgrade (mainly developers and early adopters). So forcible upgrade on freebsd-update time is insufficient (as human makes mistake).

Because some problems may arise even if you didn't upgrade the pool as in the link I posted. So, it's before upgrading any pool and even if you don't upgrade your pool(s).

Do you mean that you couldn't sanely boot / mountroot on some BEs?
After loader hands over to kernel, bootcodes does not matter anymore.
zfs.ko loaded by loader (before kernel starts, via /boot/loader.conf[.local]) and ZFS-related userland components like /sbin/zfs, /sbin/zpool, /lib/libzfs* must be in sync, at least zfs.ko should not be older than others.
Otherwise, syscalls from userland could fail. There could be other reason, but this is what I can think of for now.

For sane and safe upgrade of boot codes, it would be desirable that what read incompatible features are supported by boot codes can easily confirmed.

Fortunately, /usr/src/stand/libsa/zfs/zfsimpl.c has an array named features_for_read, but unfortunately, for example, string /boot/loader.efi does not list the array as a bulk.
If a file containing the array as text and hashes of boot codes in /boot as, for example, /boot/zfsfeatures.list is created on building boot codes, it would be helpful.

 

[Emrion]

But not all users do binary upgrade but source upgrade (mainly developers and early adopters).

They don't use freebsd-update, so no automatic bootcodes update. It makes sense.

Do you mean that you couldn't sanely boot / mountroot on some BEs?

It was what I experienced. After updating the bootcodes, no problem anymore. That said, I didn't put the analysis deeper.

 

[beneix]

Emrion : Great utility, kudos. I have an OPNSense system running ZFS that is working OK, but I would like to preemptively update the bootloader(s) to prevent future issues. Before I do, I would like to understand what the recovery method would be in case I were left with an unbootable system after running the bootloader update. What steps should I take to prepare for a possible failure? I have physical access to the unit and can use a serial console connection if required.

 

[Emrion]

Emrion : Great utility, kudos. I have an OPNSense system running ZFS that is working OK, but I would like to preemptively update the bootloader(s) to prevent future issues. Before I do, I would like to understand what the recovery method would be in case I were left with an unbootable system after running the bootloader update. What steps should I take to prepare for a possible failure? I have physical access to the unit and can use a serial console connection if required.

Preemptively you say? Just after the upgrade of the system or before, meaning you get the bootloaders of the next version and put them in a directory (and use the -s option)? I don't advise this last.

Anyway, the simplest method is to have a USB key with the current version of your OS. And when it concerns something that seats between internet and your local network, create this key before attempting any upgrade . If a problem arises, you boot on this key with the BIOS menu. Then, you can downgrade the loaders if necessary.

I never faced any trouble with the systematic update of the loaders, but I did it always after upgrade (including reboot for the new kernel takes place). It's better to reboot again immediatly to be sure that all is ok.