My installation is about 3.5 years old, and I read somewhere that before upgrading from v26.1 to v26.7, I should update the disk bootloader. Is that correct?
I ran the following command: ./loaders-update show-me
and this is the output: loaders-update v1.3.2
One or more efi partition(s) have been found.
Examining ada1p1...
mount -t msdosfs /dev/ada1p1 /mnt
Would run: cp /boot/loader.efi /mnt/efi/freebsd/loader.efi
Would run: cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
umount /mnt
Examining ada0p1...
Efi partition ada0p1 is already mounted in /boot/efi.
Would run: cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
Would run: cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
One or more freebsd-boot partition(s) have been found.
The root file system is zfs.
Examining ada1...
Would run: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1
Examining ada0...
Would run: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
-------------------------------
Your current boot method is BIOS.
Updatable EFI loader: 4
Updatable BIOS loader: 2
-------------------------------
Could some kind soul guide me on the next steps?
Tia.
Not entirely correct. You should uninstall any os-cpu-microcode-* plugin you have installed before upgrading, and update the bootloader after upgrading to 26.7. Because there's an important bootloader bug fix in FreeBSD 15.1. You can then reinstall the microcode plugin.
For updating the bootloader: just use that script. Output looks ok.
Caveat: always have a backup. Create a snapshot before you do anything.
So, (1) remove the intel cpu microcode; (2) upgrade to v26.7; (3) update bootloader.
As for point (3), is there any sort of step-by-step, fool-proof guide?
Besides: loaders-update is neither installed nor available on OpnSense, is it?
Hello.
I'm not sure if I'm in the right place here or if I'm hijacking the forum thread. If so, please accept my apologies.
My installation is getting on in years, too—four years old.
The update to 26.7 went smoothly, as usual.
Many thanks to the team!
However, before I could bring myself to proceed, I closely followed the discussion regarding the bootloader update and the "microcode problem." There were several discussions about it. This raises the question for me: who actually needs a bootloader update? And how do I determine whether I need this bootloader update?
Many thanks,
Bernd
Quote from: meyergru on July 23, 2026, 09:23:57 PMBesides: loaders-update is neither installed nor available on OpnSense, is it?
May make sense to add it if it's safe for our standard installation modes, but we need to have a few conversations first.
Cheers,
Franco
I'm not particularly tech-savvy, and judging by the number of typos I make, I may well have undiagnosed dyslexia or something similar 😄
So yes, I ask questions that may seem obvious or "silly" to more experienced users. But hey, why someone would spend his/her own time writing unhelpful replies that don't actually answer the question is totally beyond my comprehension.
That said, I must have installed the script at some point in the past, I just don't remember when or why.
I can see the output of the option help, but it doesn't help ma at all:
loaders-update v1.3.2
Usage: loaders-update mode [-befgqry] [-m efi_mount_dir] [-s loaders_source_dir]
mode can be one of:
show-me: just show the commands to type, change nothing.
shoot-me: may update the loader(s), but ask for confirmation before each one.
Options:
-b: scan only BIOS loaders (excludes EFI loaders).
-e: scan only EFI loaders (excludes BIOS loaders).
-f: won't check the freebsd-boot content for BIOS loaders update.
-g: force to use 'gpart show' for disk detection.
-q: quiet mode. No output to the console.
-r: won't check the root file system for BIOS loaders update.
-y: answer yes for shoot-me mode. Use with caution!
Return codes:
0: no error.
1: an error occured.
2: at least one loader isn't up-to-date.
3: = 1 + 2.
That's precisely why I'm asking about the correct way to update the bootloader, so if anyone knows the current recommended method, I'd genuinely appreciate the information.
Quote from: meyergru on July 23, 2026, 09:23:57 PMBesides: loaders-update is neither installed nor available on OpnSense, is it?
It was mentioned in this topic: https://forum.opnsense.org/index.php?topic=51959.0 including instructions on how to get it:
curl -O https://raw.githubusercontent.com/Emrion/uploaders/refs/heads/main/loaders-update
chmod +x loaders-update
./loaders-update show-me
./loaders-update shoot-me
It's just a script after all.
Quote from: hushcoden on July 23, 2026, 09:20:06 PMAs for point (3), is there any sort of step-by-step, fool-proof guide?
Use the matching "gpart" invocations for your legacy boot partitions and "mount_msdosfs" followed by a simple copy for your EFI partitions. Or use the script.
There is to my knowledge no better documentation and "fool proof" is difficult because the actual execution depends on a gazillion parameters all individual for each installation. That's why FreeBSD has not yet provided any automated method.
You need to understand
- your partition layout
- where your legacy boot partitions are and how to update them
- where your EFI partitions are and how to update them
Possibly the script will fail because the installer never formatted the EFI partition on your second disk. All of this needs to be taken into account.
If all of your EFI partitions actually contain a valid FAT32 file system the script will probably run just fine and perform everything necessary.
BTW: as @nero355 pointed out Linux is no better in this regard. If you create a mirrored installation you will end up with GRUB only on the first disk. The rest is left as an exercise to the admin.
Sorry I don't have better news. Go ahead and try the script, report any errors you encounter. If e.g. your second EFI partition is really not formatted properly, you can update the first and then just "dd" over the whole partition to the second drive.
If you are familiar with what a partition table is, what "dd" is etc. none of this is a big deal. If you are not go step by step and we will try our best to guide you along.
Kind regards,
Patrick
Quote from: RES217AIII on July 23, 2026, 09:28:10 PMwho actually needs a bootloader update?
Everyone because the bootloader received a fix for a severe bug in FreeBSD 15.1 which was just published and is just now included in OPNsense 26.7. One needs to keep the bootloader updated just like one needs to keep the OS updated. And the FreeBSD project offers very little help with that.
If you have just a single drive, try the loaders-update script. It will probably work out fine.
Thank you Patrick, much appreciated.
And least now I understand that it's completely beyond my capabilities, so will plan a new/fresh install.
Quote from: hushcoden on July 23, 2026, 10:28:54 PMAnd least now I understand that it's completely beyond my capabilities, so will plan a new/fresh install.
Please report back after your fresh install and I can at least guide you through getting the boot loader on the second drive.
If all you ever did was use the OPNsense installer your second drive is not bootable. Not OPNsense's fault! But it's a 50/50 gamble when one drive fails if your system still boots, despite the fact that everything else is properly mirrored.
The script is quite clever. I tested it on all my different installations, SATA, NVME and virtio, but all UEFI and it worked flawlessly.
One thing I wanted to test is if it still works in hybrid UEFI/Legacy boot mode. The standard FreeBSD installers do not work well with cross-booting. Easy to test in a VM.
Cheers,
Franco
Quote from: Patrick M. Hausen on July 23, 2026, 09:59:08 PMQuote from: hushcoden on July 23, 2026, 09:20:06 PMAs for point (3), is there any sort of step-by-step, fool-proof guide?
....
Sorry I don't have better news. Go ahead and try the script, report any errors you encounter. If e.g. your second EFI partition is really not formatted properly, you can update the first and then just "dd" over the whole partition to the second drive.
If you are familiar with what a partition table is, what "dd" is etc. none of this is a big deal. If you are not go step by step and we will try our best to guide you along.
Kind regards,
Patrick
Thanks Patrick, so in the end I went ahead and updated from v26.1 to v26.7 + I tried the script (shoot-me) to upload the bootloader too, and so far so good, this is the new output of the command show-me:
loaders-update v1.4.1
One or more efi partition(s) have been found.
Examining ada1p1...
mount -t msdosfs /dev/ada1p1 /mnt
EFI loader /mnt/efi/freebsd/loader.efi is up-to-date.
EFI loader /mnt/efi/boot/bootx64.efi is up-to-date.
umount /mnt
Examining ada0p1...
Efi partition ada0p1 is already mounted in /boot/efi.
EFI loader /boot/efi/efi/freebsd/loader.efi is up-to-date.
EFI loader /boot/efi/efi/boot/bootx64.efi is up-to-date.
One or more freebsd-boot partition(s) have been found.
The root file system is zfs.
Examining ada1...
The pmbr on this disk is up-to-date.
The freebsd-boot partition ada1p2 is up-to-date.
Examining ada0...
The pmbr on this disk is up-to-date.
The freebsd-boot partition ada0p2 is up-to-date.
-------------------------------
Your current boot method is BIOS.
One or more target partition(s) have been found...
All loaders are up-to-date.
-------------------------------
Many thanks for your support!
15.1 RC3 includes the bootloader fix. Is the v26.7 OPNsense not using RC3 build?
It is using 15.1 release. But you need to manually update your boot loader in FreeBSD after the OS upgrade. There is no automation for that at all.
Quote from: franco on July 24, 2026, 08:06:42 AMOne thing I wanted to test is if it still works in hybrid UEFI/Legacy boot mode. The standard FreeBSD installers do not work well with cross-booting. Easy to test in a VM.
Cheers,
Franco
As you may have seen, it works perfectly in hybrid configurations.
Some things to know:
- It won't put (or propose) a loader where previously there wasn't one (with an exception for freebsd-boot partition, if you use the -f option). Its goal is only to update.
- It doesn't work on MBR scheme and is likely to never change on this point. This software is only for GPT scheme.
- It supports only amd64 and arm64 arches. Knowing that the support for arm64 is recent and is less tested than amd64.
If you or anyone have any question, I will be pleased to answer.
Quote from: Patrick M. Hausen on July 28, 2026, 09:05:47 AMIt is using 15.1 release. But you need to manually update your boot loader in FreeBSD after the OS upgrade. There is no automation for that at all.
15.1-rc3 is said to have the bootloader fix in it. So I thought OPNsense 26.7.2 could use rc3, this way going from less than 26.7 you could get directly to the fixed rc3.
But it's a bit baffling, rc3 is said to be fixed, but the notes for rc3 still says you need to manually copy in a bootloader?
https://lists.freebsd.org/archives/freebsd-stable/2026-June/004124.html
Quote from: BrandyWine on July 28, 2026, 08:12:09 PM15.1-rc3 is said to have the bootloader fix in it.
Of course it does. As does 15.1 release, which OPNsense 26.7 uses. I don't get your point.
If you do a fresh installation of 15.1-rc3 or newer you will get an up to date boot loader including that particular fix. But most people arrive at OPNsense 26.7 by updating a 26.1 system. People don't reinstall all day for fun. And the FreeBSD/OPNsense update process does not touch the on disk boot loader. Never.
It drops the current updated version into /boot/loader.efi and that is that. You need to manually copy it to your EFI boot partition if you want to use it to actually, well, boot the system.
Hope that makes it clear, now.
My point is, make the OPNsense 26.7.2 version with 15.1-rc3. So when I upgrade into 26.7.2 from 26.x less than .7, I don't need to do any manual bootloader copying.
But as I noted, that URL I gave, is talking about rc3, but then goes onto say "copy in the fixed bootloader". If rc3 already has the fixed bootloader then why would I be copying it in?
Quote from: BrandyWine on July 28, 2026, 08:50:31 PMMy point is, make the OPNsense 26.7.2 version with 15.1-rc3. So when I upgrade into 26.7.2 from 26.x less than .7, I don't need to do any manual bootloader copying.
You do because the update process does not touch the boot loader installed in the EFI partition or the legacy boot partition. It only drops the latest version into the root file system for the admin to copy it to the relevant partition(s).
Quote from: BrandyWine on July 28, 2026, 08:50:31 PMmake the OPNsense 26.7.2 version with 15.1-rc3
Dude... you know 15.1 is newer than the RC3 release for 15.1 right ?!
And again : The problem are FreeBSD 14.x to 15.x upgrades and not fresh installs of FreeBSD 15.x a.k.a. OPNsense 26.7.x :)
Quote from: nero355 on July 29, 2026, 04:44:04 PMQuote from: BrandyWine on July 28, 2026, 08:50:31 PMmake the OPNsense 26.7.2 version with 15.1-rc3
Dude... you know 15.1 is newer than the RC3 release for 15.1 right ?!
And again : The problem are FreeBSD 14.x to 15.x upgrades and not fresh installs of FreeBSD 15.x a.k.a. OPNsense 26.7.x :)
15.1 Release is June 16th (a lie on their site, https://www.freebsd.org/releases/)
15.1 is actually June 12th (https://download.freebsd.org/releases/amd64/15.1-RELEASE/)
RC3 is June 6th.
What's the diff?
Release candidate 3 vs. release. Simple as that. OPNsense 26.7 is based on 15.1 release so it contains a fixed boot loader.
IF you perform a fresh installation. If it's an update from 26.1 you will still have the old boot loader in the boot partitions, both EFI and legacy.
One more question: I'm reading about whether early or late loading of the cpu microcode is better and considering I'm not experiencing any issues with the recently installed v26.7.1, I'd say there's nothing I need to do. Is that the case, or should I create the file /boot/loader.conf.local and add those two lines? cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
I just want to understand whether the early loading is strictly necessary or if it's simply recommended.
You would need to take a deep dive into Intel's or AMD's documentation, find what exactly the update does to your CPU, then assess if this is something that is necessary to be done before the FreeBSD kernel initialises.
Microcode updates are bug fixes for your CPU. I have no idea how I would find that information.
So probably early loading is somehow "better"?
But I run ~100 servers which all load late without any ill side effects.
🤷, sorry.
Also, running sysctl machdep.bootmethod I get machdep.bootmethod: BIOSShould I consider to change to UEFI? But then I have to figure out how to do so :-)
You must update your legacy boot loader.
You can update your EFI boot loader in case you ever want to upgrade your hardware by moving your drive with the installed system to a new and more modern machine.
Your decision.
How to do that has been discussed dozens of times - I'm tired of writing the same things over and over again. It's in this thread.
I already updated the bootloader and it's in this thread too at #13 - I meant whether I should have changed from legacy BIOS to EUFI within the appliance BIOS... np, forget about my question.
Again there is not really a pro or a contra for one method or the other. At least IMHO for a small appliance. For "real servers" EFI is the best invention since sliced bread. Nothing else, please.
Quote from: Patrick M. Hausen on August 09, 2026, 09:15:04 PMFor "real servers" EFI is the best invention since sliced bread. Nothing else, please.
Why exactly ?!
Apart from regular PCs and Laptops doing that fancy fast booting stuff for Consumers there is nothing that I can think of that I actually like about it to be honest...
1. Update your LSI controller firmware? Update your SSD firmware? Place the vendor update tools on the EFI partition from your running FreeBSD OS, boot into EFI shell via IPMI, update $STUFF.
2. No obscure "dd" incantations to update the boot loader. FAT32, documented directory structure, done.
3. Manage boot order with "efibootmgr" from the running OS - no need to ever go to the BIOS for that.
First points that come to my mind.