Utility that tries to figure how to update the FreeBSD loaders

I've added it to my upgrade script/flow. I appreciate it. Plus he responded to my problems within hours.
Now I don't worry about it at all.
 
After many shilly-shallying, I eventually released a new version of loaders-update that features the backup of the loaders, either the EFI and BIOS ones.

The BIOS loaders are just saved in /root, but the EFI loader benefits from the possibilities that UEFI brings. The updated loader is saved in a way that you can boot on the previous one by simply call the boot menu at the starting of the machine. So, no need to boot on a USB key to mend the system in case of boot failure.

It wasn't not been without trouble, but I can propose this now, after numerous testings.

I keep that in the 'current' branch and not in the 'main', to let the time to discover if there are some critical problems. I'm mainly thinking to ARM64 arch, I can't test. I'm especially thinking to dl8dtl who helped me in this way.

That said, anyone that will test and report here, or in the uploaders github, these new features will be of invaluable contribution.

github.com

GitHub - Emrion/uploaders at current

A proof of concept concerning the automatic update of FreeBSD loaders - Emrion/uploaders
github.com github.com
 
T-Aoki said:
Just a FYI:
Found this announcement for review at freebsd-hackers ML.

This is to add functionality to upgrade loader.efi (and bootx64.efi if appricable) for freebsd-update(8).

As written in linked post above, the relevant review is D58990.
Click to expand...
Good new.

Just a thing: writting the NVRAM can cause problems in certain circumstances. It's why I so delayed the EFI FailSafe feature.
It forces to have an entry with /efi/freebsd/loader.efi and make it first for booting (in case of creation of this entry), at first glance. It is somewhat brutal if you have a multi-boot and you don't want to start on FreeBSD by default.
 
Emrion said:
Good new.

Just a thing: writting the NVRAM can cause problems in certains circumstances. It's why I so delayed the EFI FailSafe feature.
It forces to have an entry with /efi/freebsd/loader.efi and make it first for booting (in case of creation of this entry), at first glance. It is somewhat brutal if you have a multi-boot and you don't want to start on FreeBSD by default.
Click to expand...
If I recall correctly, at least on quite early UEFI computers, no bootcode other than the ones from Windows or EFI/boot/BOOTx64.efi in ESP (the fallback default of UEFI spec) couldn't boot.

And if I recall correctly, I've heared some early UEFI computers malfunctioned when any entry other than for Windows are registered into NVRAM.

This is why I don't install multiple OS in same physical drive and make EFI/boot/bootx64.efi to be the one that can boot installed OS in the same drive after switching to UEFI boots whenever I myself install a OS.

Note that I'm using boot1.efi (patched with PR 207940) as EFI/boot/bootx64.efi for FreeBSD for my convenience.
 
What I like is the author of the patch took its inspiration from sysutils/loaders-update as he quotes it. There are many things to realize. How to guess if the efi partition is mounted, if there are some symlinks in /dev. How to analyse freebsd-boot partitions, etc.

My code isn't really simple to read, I admit. But, I didn't wrote all of this for nothing, that's for sure.

As I said in one or two threads... I was right. No matters what "knowledgeable people" said. Events show they were wrong. Dot.
 
You must log in or register to reply here.
Back
Top