Updating Bootcode

My opinions only, mileage may vary.

My primary reason I don't want an update like this buried in a tool is control. I want to control when and how it gets done because you need a reboot to actually test it and because it potentially can give you an unbootable system, you want to find it out under your control, not when you have an outage and the CEO is screaming at you to get the systems back online at 2am.

Systems based on FreeBSD have added warnings/suggestions/notices that the bootcode should be upgraded.

Root on ZFS can be highly dependent on the bootcode; if you zpool upgrade your root pool, then enable new features that your older bootcode doesn't know about/understand, you may render your system unbootable. That is one reason to be careful doing a zpool upgrade command.
One thing to remember: you can make software backwards compatible but you can't make it forward compatible. Newer bootcode can understand older zpool, but older bootcode has no idea about newer zpool

UFS may not ever require bootcode upgrade.
 
Nandor said:
What are the reasons that this must be done manually
Click to expand...
As mer explained this is considered a feature.
Doing these kinds of things manually vastly improves system stability, flexibility and stability. Automatically updating critical components of a system highly increases the risk of things going wrong being left with an unbootable system. Especially in cases where the system configuration might not adhere to a "common sense default". A simple example: Assuming you run an EFI system with ZFS-on-root with multiple disks: You'll have to update the bootloaders on all disks. Will an automatic tool handle this properly in all cases? I wouldn't want to have to trust that.

One might further argue that it's also improving security: In case of EFI you can leave your ESP unmounted reducing the risk of getting something nasty in there. I only mount my ESPs when I need to update the bootloader.

All of the above does not apply to all scenarios and extends over the GPT scheme upgrade your mentioned. The point is to illustrate that if you do one thing automatically you have to do other things automatically as well to gain the benefit of "no manual user action required" which might not be trivial.
 
jbo said:
You'll have to update the bootloaders on all disks.
Click to expand...
This is very important: toss in variations of encrypted partitions, disks, etc and it becomes even more "interesting".
Now it would be relatively trivial to write a script that maybe takes a list of "boot" devices/partitions and actually execute the command, but I keep my update instructions in a text file so I simply cut and paste, hit enter, hit up arrow, backspace, change a digit and hit enter.
You could get all kinds of fancy doing gpart list, looking for freebsd-boot or efi, mounting as needed, running the commands, unmounting. Now toss in all the error checking so you don't get into a bad situation and it's quicker to type the command in yourself.

Now if you have maybe more than 5 machines to worry about, creating that script once would be helpful in the long run.
 
Concerning BIOS booting, I agree, there are too many combinations. It would be hard for a script to understand how exactly the system boots and thus, where and how to update.

But, for efi, it's simpler I think. If the new installations with 13.x-RELEASE, default mounts /boot/efi, there is a reason. Maybe, this reason is that, soon or late, the upgrade will automatically update the efi loader if possible. Anyway, it's just an intuition.

That being said, in case of RAID1, it won't update all the disks...
 
It's not simple for EFI either. Sure, as long as loader.efi is just installed as the standard EFI binary, it is kind of easy. But people might also install it to some custom location, using e.g. efibootmgr to create an entry for it, or maybe use some custom boot manager like rEFInd, there are also lots of possibilities.

I'd really rather not attempt to automate that. After all, updating bootcode is rarely needed. The most likely reason to need it is some upgrade of your ZFS boot pool. Then, doing it manually is the safer choice for sure.
 
I have not considered the whole thing from this perspective, absolutely correct and well thought out.

By the way:
...not when you have an outage and the CEO is screaming at you to get the systems back online at 2am.
Click to expand...
made me laugh, that is something you definitely do not want.

Especially the aspect ZFS-on-root with multiple disks / RAID as well as security was not clear to me.


With all the things i don't know you can fill whole warehouses...
 
Nandor said:
With all the things i don't know you can fill whole warehouses...
Click to expand...
That applies to everybody here as well. Sure, we might have some more knowledge about FreeBSD & related topics but for example, I know absolutely nothing about riding horses, running an industrial kitchen or making a nice painting.

If you ask good & concise questions you'll usually get pretty good answers from most of the community members here. Just keep moving forward, read documentation, ask questions and you'll do just fine.
 
Last edited:
As I read in this thread, the main (and possibly the only) problem is the evolution of ZFS. The bootcodes need to know enough in order to load and run files from that system.

In pratice, you can have weird symptoms if you neglect to update bootcodes. See here: https://forums.freebsd.org/threads/why-its-important-to-upgrade-efi-boot-bootx64-efi.79503/

I don't see any problem to automatically update the efi loader during upgrade. Personnally, I reboot at each upgrade and you have to, if you want to run (and test) the new installed kernel, so you test also the bootcode.

If you have something peculiar concerning efi (and don't want automatic update of the loader) you will just have to umount /boot/efi and/or comment it out in fstab.
 
Emrion said:
I don't see any problem to automatically update the efi loader during upgrade.
Click to expand...
Which will just not work (and in the worst case even break things) if you have a non-standard EFI installation, as I explained above.

Emrion said:
Personnally, I reboot at each upgrade and you have to, if you want to run (and test) the new installed kernel, so you test also the bootcode.
Click to expand...
Testing a kernel is traditionally protected by just keeping /boot/kernel.old and having an entry for it in the bootloader, so you have a smooth rollback path. With modern ZFS boot environments, you can have rollback for the whole OS. There's no such option for the bootcode, it isn't technically possible.

Emrion said:
In pratice, you can have weird symptoms if you neglect to update bootcodes. See here: https://forums.freebsd.org/threads/why-its-important-to-upgrade-efi-boot-bootx64-efi.79503/
Click to expand...
There's a reason zpools aren't upgraded automatically either.
 
We will see where FreeBSD will heading on this matter. Because I wonder why /boot/efi is now mounted by default.

I wasn't speaking of automatically upgrade zpools. This is a related but different beast.

If you think about all the problems, there is a simple solution for all of them. I gave one of them, but it seems you didn't read my words.
 
Emrion said:
That was made in 2019 and since, this has not been committed. But, the need, the means and the idea are here. I bet we will see something like that during the upgrade process in the future.
Click to expand...
Not likely. The sheer amount of comments there tells a story. And the final comment is there for a reason as well, most likely the reason I actually explained to you.

That said, what might be possible is having some convenience script that could be executed manually. Sure, why not. I personally don't need it though....
 
Same as, during the upgrade process:
Do you want to update your efi loader(s) (yes/no)?
Click to expand...

I totally agree that it's better to do some things manually, but I don't believe it's the case for this one. Nor, I think that FreeBSD should keep the problem of some kernel modules mismatch at each minor version. It's not only very annoying, this can lead to a disaster if the user/admin doesn't know all the particularities, not to say problems, about FreeBSD.

So, when you tell me that there is no rollback for loader, what will be the rollback to leave the efi loader not updated for a longtime? The system will become unbootable and that's for sure concerning ZFS.

PS : in this case, you plug an USB key and start on it, simple. :)
 
Emrion said:
The system will become unbootable and that's for sure concerning ZFS.
Click to expand...
It won't. Unless you upgrade your pool. Which will tell you you also must upgrade your bootcode.

But maybe reading what's written on the screen ist just overrated. ?‍♂️
 
Emrion said:
Last time I saw such a warning, it spoke only about gpart, pmbr and the like. Hope that has changed since.
Click to expand...
It gives one simple and concise example. Maybe this should better be removed, people seem to misinterpret it as "do exactly this".

There's no way to give full instructions what exactly to do for "updating bootcode", as possibilities are close to endless. Even this script referenced above about EFI bootcode just attempts to identify a few "common cases" and only do anything at all when this is successful (and it's still not 100% safe).

I explained this to you several times now, it really gets boring.
 
You explained nothing except you do not agree with this idea. It's ok, it's your opinion, but please don't dismiss other thinking. End of discussion for me.
 
Phew, I'm just amazed at what (for me) such a "simple question" can spark.

But for me as an amateur and beginner this has brought a lot for me.

It all started for me a long time ago [Grandpa tells stories from the old days] when an upgrade from 13.0 to 13.1 stalled at boot time on one of my boxes.
Some ZFS error I don't remember; was also a headless box, so every reboot some fiddling around with you know what I mean.
Since I did not know where to start, my research was very fruitless; especially since currently the info in the Handbook was very meager and for me rather so: "Whut?"
So I gave up and "re-installed" 13.1 [Booing from the audience].

By chance I then came across the thread that led to my original question.
Fast forward to the present day; what have i learned through this:

- don't just give up because a solution is not apparent (reinstalling is also a possible solution but no gain in knowledge for me).
- Dare to ask silly questions sometimes (Thanks jbo btw) and do so in the right place (here).
- RTFM/screen messages thoroughly and carefully, several times. (I'm absolutely with you zirias@)
- Just because something can be automated it must therefore also be done (mer approach or implementation I find more and more interesting [...update instructions in a text file...])

Bottom line for me: Should there ever be an automated solution (yes/no) I would not use it (See above for reasons).


PS: Hi Emrion, thanks for the tips and support on the topic. At that time it would certainly have helped me in the meantime, however, see this current post of mine.


Thanks again to all for your attention, support and time!
Nandor
 
Nandor I do that because easier for me to make sure I don't miss any steps. I'm more than happy to send you a message with what I have. It's not original thoughts, in fact a lot came from vermaden who's posted "how to upgrade into a new BE" and others like klarasystems and the standard instructions from the FreeBSD website.
 
You must log in or register to reply here.
Back
Top