OP
- Thread Starter
- #26
About failsave when loaders are updated.
I read that some (many?) people are frightened to update their loaders. For a certain point of view, it makes sense. Often, when you do a serious mistake on your system, you can have anyway a boot prompt or a single user shell. You might get nothing if the loader doesn't make its job.
My answer was: you can plug a USB key with the previous FreeBSD version and you will able to fix the problem.
Well, this is just my idea, This doesn't prevent to think to this challenge. I saw no possibility for BIOS booting, but concerning EFI booting, it's simpler than I thought.
In "recent" FreeBSD installations, you have two efi loaders in the EFI partition (examples on amd64 system):
/efi/boot/bootx64.efi and /efi/freebsd/loader.efi.
In these more recent installations, you have an efi var, first in order for booting, that is pointing on /efi/freebsd/loader.efi.
Beware that ancient installations may have only /efi/boot/bootx64.efi. You can see that simply by seeing the content of your ESP partition. You have also to check the boot order with
In the case, you are on a "new" installation, you may only update /efi/freebsd/loader.efi. If a problem arise with the new loader, you will able to call the UEFI boot menu (typically by pressing F11 or F12). There, you might select something like "UEFI HD (...)" instead of the default "FreeBSD HD (...)".
Once the new installed loader is working for sure, don't forget to update also /efi/boot/bootx64.efi. Because, if you dont do so, you will have a failsafe loader of two versions behind the current at next update.
If you don't have both loaders or if you want to go further in this logic, we can create an efi var.
Before to update the loader(s), you copy the old one. For example:
Then you can create the corresponding efi var:
Unfortunately, this command will also put the newly created efi var in first position for boot. It's not what we want. So, we must redefine the boot order like it was before the creation of this var, and add this one at the end, for instance. What matters is it doesn't be first in boot order.
Example:
Once this done, you will find in the UEFI boot menu something like: "PreviousVersion HD (...)"
Then, at each loaders update, you will have just to copy the ancient loader to /efi/boot/old-loader.efi before to update with the new one. And you will have always a failsafe loader.
Of course, I'm thinking to possibly incorporate such a mecanism in loaders-update, but the work I had to do is huge. You see, it should guess what is the boot disk and only place the failsafe logic on it. It's not impossible, but it's tricky.
I read that some (many?) people are frightened to update their loaders. For a certain point of view, it makes sense. Often, when you do a serious mistake on your system, you can have anyway a boot prompt or a single user shell. You might get nothing if the loader doesn't make its job.
My answer was: you can plug a USB key with the previous FreeBSD version and you will able to fix the problem.
Well, this is just my idea, This doesn't prevent to think to this challenge. I saw no possibility for BIOS booting, but concerning EFI booting, it's simpler than I thought.
In "recent" FreeBSD installations, you have two efi loaders in the EFI partition (examples on amd64 system):
/efi/boot/bootx64.efi and /efi/freebsd/loader.efi.
In these more recent installations, you have an efi var, first in order for booting, that is pointing on /efi/freebsd/loader.efi.
Beware that ancient installations may have only /efi/boot/bootx64.efi. You can see that simply by seeing the content of your ESP partition. You have also to check the boot order with
# efibootmgr -v.In the case, you are on a "new" installation, you may only update /efi/freebsd/loader.efi. If a problem arise with the new loader, you will able to call the UEFI boot menu (typically by pressing F11 or F12). There, you might select something like "UEFI HD (...)" instead of the default "FreeBSD HD (...)".
Once the new installed loader is working for sure, don't forget to update also /efi/boot/bootx64.efi. Because, if you dont do so, you will have a failsafe loader of two versions behind the current at next update.
If you don't have both loaders or if you want to go further in this logic, we can create an efi var.
Before to update the loader(s), you copy the old one. For example:
# cp /boot/efi/efi/boot/bootx64.efi /boot/efi/efi/boot/old-loader.efi. It assumes that your EFI partition is mounted in /boot/efi/.Then you can create the corresponding efi var:
# efibootmgr -c -a -l /boot/efi/efi/boot/old-loader.efi -L PreviousVersion.Unfortunately, this command will also put the newly created efi var in first position for boot. It's not what we want. So, we must redefine the boot order like it was before the creation of this var, and add this one at the end, for instance. What matters is it doesn't be first in boot order.
Example:
# efibootmgr -o 1,0,2,3,4 (Boot0004 is the newly created var).Once this done, you will find in the UEFI boot menu something like: "PreviousVersion HD (...)"
Then, at each loaders update, you will have just to copy the ancient loader to /efi/boot/old-loader.efi before to update with the new one. And you will have always a failsafe loader.
Of course, I'm thinking to possibly incorporate such a mecanism in loaders-update, but the work I had to do is huge. You see, it should guess what is the boot disk and only place the failsafe logic on it. It's not impossible, but it's tricky.