Im one of those who had problem to upgrade to 25.7 with microcode installed.
I have started to play with snapshots and microcode is not root cause.
After connecting monitor I saw:
******************************************************
** BOOT LOADER IS TOO OLD. PLEASE UPGRADE. **
******************************************************
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
console vidconsole is invalid!
Available consoles:
efi
comconsole
nullconsole
spinconsole
And then freeze.
After running those commands upgrade went smoothly even with microcode installed (FOR OTHERS DO NOT COPY PASTE-DANGEROUS !!!)
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nda0
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
Any idea why this happens?
After 25.7 upgrade I re-run those commands, because loader.efi in efi partition was not updated to newest version.
I am having the same issues. Opnsense is not booting.
To get up and running, on boot, I needed to boot to previous kernel. Once up and running, I logged into opnsense and deleted the intel microcode update pluggin. I then rebooted and the system came up in OPNsense 25.7-amd64 FreeBSD 14.3-RELEASE-p1.
It was a bit scary at first as I kept getting message that firmware needed to be updated.
How can I find out whether my FreeBSD was booted as EFI or BIOS? In Linux I just check for /sys/firmware/efi but no idea how to determine this in FreeBSD.
I also never switched to ZFS. I have been using UFS since I installed OPNsense in 2021 and only upgraded OPNsense since then.
You cannot upgrade to ZFS. Switching from UFS to ZFS needs a complete reinstall. So you are probably still running UFS.
To determine how your system boots use
sysctl machdep.bootmethod
HTH,
Patrick
Perfect, thanks for the info. As you might have guessed I am not a FreeBSD person. ;-)
So, my system uses UEFI. But according to the posts in this topic it seems that the bootloader is not updated during an update.
I've updated my system since 2021 (thus 8 OPNsense versions) and the major upgrades never updated the bootloader? So I'm using a 4 year old bootloader?
One has to do this manually? All fine and good, but this was never mentioned anywhere nor how to do that. (If the system complains during an upgrade, it's too late, especially on a headless system.)
Is there any information about how to update the boot loader on an OPNsense system?
About ZFS: Yep, I know that ZFS would require a new install. That's not really the issue, since it's a breeze to restore a previous config. But I don't have ECC RAM in that miniPC and thus won't use ZFS. Additionally ZFS usually eats a lot of RAM. IMO ZFS has no advantage on a FW that basically runs from a single filesystem. I use ZFS on my Proxmox server and there it makes perfect sense.
Quote from: tessus on July 27, 2025, 07:05:45 AMSo, my system uses UEFI. But according to the posts in this topic it seems that the bootloader is not updated during an update.
I've updated my system since 2021 (thus 8 OPNsense versions) and the major upgrades never updated the bootloader? So I'm using a 4 year old bootloader?
Yes.
Quote from: tessus on July 27, 2025, 07:05:45 AMOne has to do this manually?
Also yes, but definitely an upstream issue. There are just too many possible boot configuration/topologies to come up with a general solution. Just assuming a particular partition layout has a high probability of destroying your boot loader completely. So for now it's left as an exercise to the admin. I wonder if there is any progress being made in that direction. If yes, I will probably know in September (EuroBSDCon 2025).
Quote from: tessus on July 27, 2025, 07:05:45 AMIs there any information about how to update the boot loader on an OPNsense system?
FreeBSD handbook I guess. But then again probably nobody knows from the top of their heads how exactly OPNsense partitioned the disk back in 2021. So please post the output of
cat /etc/fstab
gpart showand I will lead you through the process.
Quote from: tessus on July 27, 2025, 07:05:45 AMAbout ZFS: Yep, I know that ZFS would require a new install. That's not really the issue, since it's a breeze to restore a previous config. But I don't have ECC RAM in that miniPC and thus won't use ZFS. Additionally ZFS usually eats a lot of RAM. IMO ZFS has no advantage on a FW that basically runs from a single filesystem. I use ZFS on my Proxmox server and there it makes perfect sense.
Not having ECC being a problem aka the "scrub of death" is a myth that has been debunked countless times yet it seems to stick ;-)
https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
Apart from that ZFS has a lot of advantages even for an appliance. Foremost resilience against power outages which have frequently lead to unbootable systems for some users on the forum with UFS. And of course snapshots and rollback. That's just awesome.
Kind regards,
Patrick
Hello,
I'm tracking this as well, as my firewall refused to boot after I accidentally upgraded to 25.7 when trying to grab the EOL 25.1.12 release.
I've since rolled back, but I did notice the BOOTLOADER TOO OLD message in the serial console.
I've got the intel-microcode package installed.
I'm running on ZFS (which is how I was able to fix my broken system so quickly--thank god for snapshots).
OPNSense 27.1.12 reports:
# uname -a
FreeBSD Uhura.finchisland.net 14.2-RELEASE-p4 FreeBSD 14.2-RELEASE-p4 stable/25.1-n269832-6addeda7db20 SMP amd64
root@Uhura:~ # cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/gpt/efiboot0 /boot/efi msdosfs rw 2 2
/dev/nvd0p3 none swap sw 0 0
root@Uhura:~ # gpart show
=> 6 122096635 nda0 GPT (466G)
6 66560 1 efi (260M)
66566 128 2 freebsd-boot (512K)
66694 122 - free - (488K)
66816 2097152 3 freebsd-swap (8.0G)
2163968 119932672 4 freebsd-zfs (458G)
122096640 1 - free - (4.0K)
@Patrick, I'd appreciate any advice on how to actually update the bootloader without a clean install.
Or, in the alternative, confirmation that I might as well just do a clean install. :P
@Sinister Pisces - this applies to your partition layout and device names.
@tessus - if yours are identical, go ahead. If not, please post your fstab and partition table, too.
Update EFI boot loader - the partition is mounted, already, so that's easy.
mkdir -p /boot/efi/efi/boot /boot/efi/efi/freebsd
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
I prefer to not have the EFI partition mounted all the time - if you agree, change fstab
/dev/gpt/efiboot0 /boot/efi msdosfs rw 2 2
to
/dev/gpt/efiboot0 /boot/efi msdosfs rw,noauto 2 2
Update BIOS boot loader, too, just in case you might switch hardware and want to just transfer the installed drive(s).
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nda0
HTH,
Patrick
Hi Patrick,
Thanks a bunch for the reply and the explanation. I certainly understand that there are a lot of boot loader configs out there. But as we can figure out which is which, so can a bootloader upgrade script/binary. The only issue is when there is ambiguous output, in which case such an automated bootloader upgrade must be aborted.
However, I also don't have a problem doing it manually. In fact I am even more comfortable by doing such an upgrade manually. But this info should be readily available in an upgrade document. (e.g. for certain Linux distros there is a section in the OS upgrade document that reads "Update bootloader on BIOS/UEFI systems")
If the OPNsense team doesn't want to add this info (due to maintenance burden) to the docs, they could maybe add a link to how this is done for BIOS and UEFI systems. This would already help a lot. I really suck with FreeBSD, otherwise I would have already created a doc PR.
Quote from: Patrick M. Hausen on July 27, 2025, 02:40:55 PMplease post the output of
Code Select Expand
cat /etc/fstab
gpart show
and I will lead you through the process.
Awesome, thanks. Yep, mine looks a bit different. This operation is way too dangerous for me to deduce from something similar. ;-)
(If it was the same, ok.) Here's the info:
root@cator00r:~ # uname -a
FreeBSD cator00r.local 14.2-RELEASE-p4 FreeBSD 14.2-RELEASE-p4 stable/25.1-n269832-6addeda7db20 SMP amd64
root@cator00r:~ # cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/gpt/rootfs / ufs rw 1 1
/dev/gpt/swapfs none swap sw 0 0
root@cator00r:~ # gpart show
=> 40 234441568 ada0 GPT (112G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 215567272 3 freebsd-ufs (103G)
215977936 16777216 4 freebsd-swap (8.0G)
232755152 1686456 - free - (823M) Quote from: Patrick M. Hausen on July 27, 2025, 02:40:55 PMNot having ECC being a problem aka the "scrub of death" is a myth that has been debunked countless times yet it seems to stick ;-)
https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ (https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/)
Apart from that ZFS has a lot of advantages even for an appliance. Foremost resilience against power outages which have frequently lead to unbootable systems for some users on the forum with UFS. And of course snapshots and rollback. That's just awesome.
Yep, there is also this disussion which is pretty interesting: ECC vs Non-ECC RAM for TrueNAS | TrueNAS Tech Talk (T3) E007 (https://www.youtube.com/watch?v=mTtJjc56nZQ)
My current main reason was rather the RAM usage of ZFS. I know, I can tweak certain parameters and so on. But to be fair, my little miniPC only supports a 8GB chip max. Although you might be correct. For my current setup this should be more than enough. I certainly like ZFS' snapshot capability.
,
Well, I might do a reinstall at one point. Who knows? If something goes wrong with my 25.1 -> 25.7 upgrade, I will have to attach a monitor and keyboard anyway. In that case I can reinstall it with ZFS...
I also agree with your statement regarding power outages. Which is why I have multiple UPS. ;-)
Hello! There is a small utility (https://github.com/Emrion/uploaders) for checking the bootloader.
To be clear, does this need to be done if OPNsense is running on UFS, or is this a ZFS exclusive issue?
This has to be done either way. The bootloader has a few stages, so depending on BIOS/UEFI/filesystem/partition layout the boot loader process differs. This is why there are different instructions for how to update the bootloader. In traditional BIOS systems the bootloader was put in the MBR (master boot record) of the first disk. At one point some bootloaders became so big that they didn't fit in the MBR and thus required their own little partition.
In UEFI systems the bootloader is located on a partition that is specific to EFI. A disk for a UEFI bootloader also uses the GUID Partition Table (GPT), while the legacy BIOS systems use the MBR or a hybrid setup.
The filesystem of the operating system (and/or on additional disks) is a different story. It might also be interesting to know that the /boot filesystem can be in one of many formats these days.
To summarize: updating the bootloader has to be done (or better said "should be done") no matter the filesystem in use. Many OS distros suggest to update the bootloader on every major release.
Quote from: Patrick M. Hausen on July 27, 2025, 10:15:40 PMI prefer to not have the EFI partition mounted all the time [...]
Good tip. Thanks Patrick!
@tessus could you add
gpart show -l
please?
Sorry duplicate post
Quote from: Chunkers on July 28, 2025, 04:54:21 PMHi all,
I am unable to upgrade to 25.7, it very quickly becomes unstable and crashes. I am have made several attempts by doing a full reinstall and uploading my config.xml and now need to try something different before trying again !
I am also not very familiar with FreeBSD, I would be very grateful for advice on suggested changes, here are the outputs for my router :
Quoteroot@opnsense:~ # sysctl machdep.bootmethod
machdep.bootmethod: UEFI
Quoteroot@opnsense:~ # gpart show -l
=> 40 488397088 nda0 GPT (233G)
40 24 - free - (12K)
64 532480 1 efifs (260M)
532544 1024 2 bootfs (512K)
533568 471086448 3 rootfs (225G)
471620016 16 - free - (8.0K)
471620032 16777096 4 swapfs (8.0G)
Quoteroot@opnsense:~ # cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/gpt/rootfs / ufs rw 1 1
/dev/gpt/efifs /boot/efi msdosfs rw 2 2
/dev/gpt/swapfs none swap sw 0 0
Quoteroot@opnsense:~ # uname -a
FreeBSD opnsense.home 14.2-RELEASE FreeBSD 14.2-RELEASE stable/25.1-n269614-36155813721 SMP amd64
Any advice would be most appreciated, I have reinstalled 25.1 and my router is running well for now now but I am unable to upgrade
Thank you
Chunks
The boot loader is not in any way connected to instability of the running system. If a newly installed 25.7 boots, the loader is fine.
OK, thank you Patrick
Thanks @Patrick for the helpful information. I've been using OPNsense for 3 years and did not know about this.
Thanks @Slashing for posting that utility. The utility can also be used to update the boot loaders. It worked great for me.
Quote from: Slashing on July 28, 2025, 01:39:12 AMHello! There is a small utility (https://github.com/Emrion/uploaders) for checking the bootloader.
I have never compiled anything from scratch on my OPNsense system. How would I go about installing this utility?
Quote from: beneix on July 28, 2025, 06:00:16 PMQuote from: Slashing on July 28, 2025, 01:39:12 AMHello! There is a small utility (https://github.com/Emrion/uploaders) for checking the bootloader.
I have never compiled anything from scratch on my OPNsense system. How would I go about installing this utility?
No compilation required, it's just a script. Download it, chmod +x it and run it as root.
Quote from: Slashing on July 28, 2025, 06:51:52 PMNo compilation required, it's just a script. Download it, chmod +x it and run it as root.
Doh! Thanks
So there is a general recommendation to keep your bootloader up-to-date, but I am not sure I understand how this utility achieves this. Am I to understand that there is updated code in one place on the disk but this has not been copied to the right place? My output from the utility is:
One or more efi partition(s) have been found.
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 ada0...
Would run: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
-------------------------------
Your current boot method is BIOS.
Updatable EFI loader: 2
Updatable BIOS loader: 1
-------------------------------
A FreeBSD update installs current boot code matching the operating system and even more importantly ZFS version to the /boot directory.
But this is not what the system actually uses to boot. Due to idiosyncrasies of the PC architecture the boot loader needs to be copied to special partitions depending on the boot method (legacy BIOS or UEFI).
The script supposedly does that.
Your dry run output looks very reasonable. I would give a live run a try - at a convenient time when an outage is not a huge problem.
Cue Riddick: "Looks clear!" :-)
Kind regards,
Patrick
P.S. A default OPNsense installation always creates a legacy and a UEFI boot partition. I advise to keep both up to date. Eventually you will replace your hardware and plan to just swap the SSD to the new system - which uses "the other" boot method. Duh! So keep both updated.
@Patrick Sure, here you go:
root@cator00r:~ # gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 409600 1 (null) (200M)
409640 1024 2 bootfs (512K)
410664 215567272 3 rootfs (103G)
215977936 16777216 4 swapfs (8.0G)
232755152 1686456 - free - (823M)
@tessus add an /etc/fstab entry like so:
/dev/ada0p1 /boot/efi msdosfs rw,noauto 2 2
Then:
mkdir -p /boot/efi
mount /boot/efi
mkdir -p /boot/efi/efi/boot /boot/efi/efi/freebsd
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
umount /boot/efi
And to update the legacy boot loader:
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
That should do it.
HTH,
Patrick
Thank you.
I do understand the process, but I have 2 questions:
Quote from: Patrick M. Hausen on July 28, 2025, 09:07:27 PMmkdir -p /boot/efi/efi/boot
This directory already existed and had the following entries:
root@cator00r:/boot/efi/efi/boot # ll
total 385
-rwxr-xr-x 1 root wheel 393216 Apr 16 2018 BOOTx64.efi
-rwxr-xr-x 1 root wheel 12 Apr 16 2018 startup.nsh
root@cator00r:/boot/efi/efi/boot # cat startup.nsh
BOOTx64.efimsdosfs is case-insensitive, so all should be good. Or shall I change the contents of startup.nsh to lowercase?
Quote from: Patrick M. Hausen on July 28, 2025, 09:07:27 PMgpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
Isn't this for zfs? Shouldn't I rather use (I am still using ufs currently):
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0
First question: mkdir -p makes sure a path exists without throwing an error if it does already. So no problem, I included it for completeness sake.
Second question: yes, probably - my bad. I don't have any UFS based systems, anymore.
@benix, the utility recommends the commands to run. You'll need to run those commands to do the update. Or you can run the utility with the "shoot-me" option and it will prompt/run each command for you.
I think I just destroyed my system.
It seems the bootfs partition is not big enough:
# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 100G 15G 77G 16% /
devfs 1.0K 0B 1.0K 0% /dev
devfs 1.0K 0B 1.0K 0% /var/dhcpd/dev
devfs 1.0K 0B 1.0K 0% /var/unbound/dev
/usr/local/lib/python3.11 100G 15G 77G 16% /var/unbound/usr/local/lib/python3.11
/lib 100G 15G 77G 16% /var/unbound/lib
/dev/ada0p1 779K 779K 0B 100% /boot/efi
So I was able to update the file in /boot/efi/efi/boot but the there is no more space for the file in /boot/efi/efi/freebsd
The bootfs is just 512KB.
P.S.: my question ws not about mkdir -p but the startup.nsh file
First: don't reboot :-)
Second: the startup.nsh is not necessary
Third: the system will boot just fine with just /boot/efi/efi/boot/bootx64.efi
So I would:
rm -r /boot/efi/efi
mkdir -p /boot/efi/efi/boot
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
Then check if there is enough free space to also create and populate the FreeBSD subdirectory. But it's not strictly necessary.
The reason of all this is historical. The concept behind EFI is to have a sufficiently large FAT32 partition and in there a structure roughly like this:
efi/freebsd/loader.efi
efi/windows/something.efi
efi/debian/something.efi
...
and then to be able to pick the OS at boot time or at least set a fixed OS in the BIOS setup.
And then there is a fallback path that is according to the standard only to be used on removable media - e.g. DVSs or USB drives:
efi/boot/bootx64.efi
or
efi/boot/aarch64.efi - if you are running on 64 bit ARM.
But it's supposed to be only a fallback.
FreeBSD when introducing EFI support got it wrong and
- installed to efi/boot/bootx64.efi
- made the EFI partition way to small
Which leads to the situation you have now.
So, delete everything, create the efi/boot/bootx64.efi path only - your system should (!) boot fine after that.
Plan some time for a reinstallation with ZFS and a reasonably large EFI partition ;-)
HTH,
Patrick
Ok, I have removed the /boot/efi/efi/freebsd again. At least the file fit in /boot/efi/efi/boot
Quote from: Patrick M. Hausen on July 28, 2025, 09:56:40 PMPlan some time for a reinstallation with ZFS and a reasonably large EFI partition ;-)
I suppose the sizing will be done by the OPNsense installer, will it not?
I have always thought that migrating to ZFS works like this:
- Save config
- Reinstall (which wipes out everything) using the OPNsense.iso on a USB stick
- Restore config
Thus I also thought that the installer would create the layout for my disk. Well, even if it doesn't, I will certainly make the bootfs bigger than 512KB. It's an overkill, but I will go for 5 or 10MB.
The more interesting question is, whether I can restore a 25.1.12 config on a 25.7.x system. I suspect it is possible, but it doesn't hurt to ask. In that case, I will do a fresh install of 25.7 when I find the time to hook up a monitor and keyboard.
Quote from: tessus on July 28, 2025, 08:54:23 PM@Patrick Sure, here you go:
root@cator00r:~ # gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 409600 1 (null) (200M)
409640 1024 2 bootfs (512K)
410664 215567272 3 rootfs (103G)
215977936 16777216 4 swapfs (8.0G)
232755152 1686456 - free - (823M)
Maybe first correct the file system type from null to efi? For example - "gpart modify -i 1 -t efi ada0"
Quote from: tessus on July 28, 2025, 10:13:21 PMI suppose the sizing will be done by the OPNsense installer, will it not?
Yes, absolutely. It will completely wipe the disk and create a new layout. Including updated partition labels and fstab.
And yes, a 25.1 config can be imported to a 25.7 system.
Quote from: Slashing on July 28, 2025, 10:18:39 PMMaybe first correct the file system type from null to efi? For example - "gpart modify -i 1 -t efi ada0"
Yes. Thanks for noticing and posting.
The entire layout seems to be an artifact of an outdated FreeBSD installer. Not OPNsense's fault in particular. Best fixed by reinstalling.
Quote from: Slashing on July 28, 2025, 10:18:39 PMQuote from: tessus on July 28, 2025, 08:54:23 PM@Patrick Sure, here you go:
root@cator00r:~ # gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 409600 1 (null) (200M)
409640 1024 2 bootfs (512K)
410664 215567272 3 rootfs (103G)
215977936 16777216 4 swapfs (8.0G)
232755152 1686456 - free - (823M)
Maybe first correct the file system type from null to efi? For example - "gpart modify -i 1 -t efi ada0"
Now I am getting really confused:
root@cator00r:~ # gpart show
=> 40 234441568 ada0 GPT (112G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 215567272 3 freebsd-ufs (103G)
215977936 16777216 4 freebsd-swap (8.0G)
232755152 1686456 - free - (823M)
root@cator00r:~ # gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 409600 1 (null) (200M)
409640 1024 2 bootfs (512K)
410664 215567272 3 rootfs (103G)
215977936 16777216 4 swapfs (8.0G)
232755152 1686456 - free - (823M)So one shows
EFI, and with the -l option it shows
(null)Then you asked me to put in fstab
/dev/ada0p1 with mount point
/boot/efiada0p1 is the 2nd partition (bootfs) and not the 200MB EFI
At least on Linux partitions are always 0-indexed, I suppose it is the same on FreeBSD. gpart just shows them 1-indexed.
So now I am rather confused.
P.S.: confused why they are shown s EFI and (null), not about mounting the bootfs (that was only because you mentioned to size the EFI partition differently, even though you probably meant the bootfs)
Quote from: Patrick M. Hausen on July 28, 2025, 10:20:42 PMYes, absolutely. It will completely wipe the disk and create a new layout. Including updated partition labels and fstab.
And yes, a 25.1 config can be imported to a 25.7 system.
Thanks, very nice. That should make things a lot easier.
(null) is the label - there is none. That's the output of "gpart show -l" as opposed to just "gpart show". Sorry, I was equally confused. Your partition type (efi) is ok.
ada0p1 is the first partition (efi). ada0p2 would be the second one (freebsd-boot). See the output of "gpart show". The partitions start at 1, not at 0.
Thanks again for your reply. One last question (or actually 2). For me there are 2 OPMsense images relevant: vga (I used this type in 2021 when I installed OPNsense) and dvd.
Both fit on an USB stick so I don't see why there are 2 types. The explanation also seems to be the same:
vga: USB installer image with live system capabilities running in VGA mode as GPT boot. On amd64, UEFI boot is supported as well.
dvd: ISO installer image with live system capabilities running in VGA mode. On amd64, UEFI boot is supported as well.
What's the actual difference and which one should I use?
For USB: vga
For burning to a DVD: dvd
See, this is what I don't understand. You can flash a DVD iso to an USB stick as well. And it boots. So I don't understand the difference.
Anyway, I'll just use the vga one. Thanks for all your help.
Not necessarily - some systems treat USB drives as a hard disk and won't boot an ISO file system from them. The other way round a DVD must contain an ISO image and not a generic hard disk one.
Quote from: Patrick M. Hausen on July 28, 2025, 11:17:18 PMNot necessarily - some systems treat USB drives as a hard disk and won't boot an ISO file system from them.
This is interesting. I've never run into this issue, ever. Luck, I guess.
Quote from: Patrick M. Hausen on July 28, 2025, 11:17:18 PMa DVD must contain an ISO image and not a generic hard disk one.
Yep, that I knew.
Anyway I hope you are successful in reinstalling/upgrading your system. Unfortunately there's a lot of history and technical debt involved in this whole mess.
I cannot speak for OPNsense but I guess their stance is "we are an appliance, reinstall and import your configuration and you will be fine."
The FreeBSD project has some work to do to come to a general solution. E.g. how OPNsense installs the boot partitions - always both - is not how I do it with short of 100 servers in my data centre. They have - depending on the platform - only a legacy or an EFI partition. That of course changes partition numbers compared to OPNsense so a "fool proof" runbook to upgrade your boot loader is a real challenge.
I will look into that script linked into this thread and take it to the FreeBSD developer summit in September.
Kind regards,
Patrick
Quote from: Patrick M. Hausen on July 28, 2025, 11:46:04 PMI cannot speak for OPNsense but I guess their stance is "we are an appliance, reinstall and import your configuration and you will be fine."
I am ok with that, in a sense (pun intended). This is a valid argument and the only issue I have is that my OPNsense is headless. Connecting stuff to it is a hassle. I usually like to avoid it. So I am happy, if I just, upgrade, upgrade, upgrade. But at one point "old" issues catch up (my very small bootfs, old BIOS, old bootloader) and there is no other choice than doing a fresh install. And of course it probably wouldn't hurt to use ZFS instead of UFS.
Either way, OPNsense upgrades always went well and I am very impressed that all the major upgrades didn't mess up my firewall and always booted up again. (I read in this forum that people often had to reinstall after a major upgrade. This never happened to me.)
I investigated a little bit and couldn't find a description of what constitutes a "too old" boot loader in a stable FreeBSD series from 14.2 to 14.3. I also do not remember this happening ever before.
Not that I'd favour starting to try and upgrade the boot loaders now, but the tiniest amount of precision from upstream on the matter would be something that should be in the actual release documentation to make that a possibility?
Cheers,
Franco
Quote from: Patrick M. Hausen on July 28, 2025, 09:56:40 PMPlan some time for a reinstallation with ZFS and a reasonably large EFI partition ;-)
First of all, thanks for all your help! Just a question for the future - do I understand you correctly that if the boot partition is 512K it would be a good idea to plan for a repartitioning followed by a reinstall at some convenient point in the future? I run ZFS and my gpart output looks like this:
# gpart show -l
=> 40 234441568 ada0 GPT (112G)
40 532480 1 efiboot0 (260M)
532520 1024 2 gptboot0 (512K)
533544 984 - free - (492K)
534528 16777216 3 swap0 (8.0G)
17311744 217128960 4 zfs0 (104G)
234440704 904 - free - (452K)(I realise that the boot partition size is not a current issue but a theoretical future one.) I don't suppose there is a way to do a repartitioning in situ without a full reinstall?
@beneix may I ask when you installed your system?
I thought that newer installer images create a bigger bootfs partition... If that's not the case, maybe there is a way to change that during install.
I first set up my OPNsense install in August 2022, which means 22.7, and it made a 260MB EFI partition at the time. I'm assuming that was done by the OPNsense installer, as I don't remember having the ability to change partition sizes.
Quote from: tessus on July 29, 2025, 07:47:34 AM@beneix may I ask when you installed your system?
The system was purchased in 2022 and I installed UFS. Then in 2024 I decided to take the leap and re-install with ZFS - I think it was when 24.7.1 was out. I don't recall giving any particular input to sizing, I think I just let the installer set the defaults, but I could be wrong.
Thanks for the info.
Please ignore the next paragraph. (Keeping it for some laughs.) I must have been out of my mind...
The bootloader is not in the EFI partition but in the bootfs partition. When I installed OPNsense in 2021, the bootloader was less than 300KB and now it's 658432 bytes. I am a bit fuzzy as to why it says 512KB for my bootfs partition, because when I mount it, it's actually 779K. So I am really lucky, because otherwise the 658432 bytes wouldn't have fit. But according to most manuals, one should actually copy the loader twice and this will definitely not work with the current 512KB bootfs partition. So in a few years the bootloader is bigger than the partition and then it's over.
You cannot mount the legacy boot loader partition. It does not contain a file system. That's the partition you write with this command:
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 2 ada0
And if you look at /boot/gptboot or /boot/gptzfsboot they are way below 200k in size so a 512k partition is more than enough.
What you can mount is EFI partition which is FAT32 formatted. And 779k is too small for that nowadays. 260M as the OPNsense installer creates now, OTOH, is again more than enough.
Partition 2: legacy boot loader - 512k
Partition 1: EFI - 260M
"bootfs" is just a label, it does not in any way say that there is an actual file system on that one.
HTH,
Patrick
Patrick, you told me to add the following to my fstab:
/dev/ada0p1 /boot/efi msdosfs rw,noauto 2 2
I did that and when I mounted it, df showed me the following:
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 100G 15G 77G 16% /
devfs 1.0K 0B 1.0K 0% /dev
devfs 1.0K 0B 1.0K 0% /var/dhcpd/dev
devfs 1.0K 0B 1.0K 0% /var/unbound/dev
/usr/local/lib/python3.11 100G 15G 77G 16% /var/unbound/usr/local/lib/python3.11
/lib 100G 15G 77G 16% /var/unbound/lib
/dev/ada0p1 779K 644K 135K 83% /boot/efi
So something is wrong with your last comment, because I mounted the legacy bootloader with the commands you gave me.
Th only other explanation is that my 200MB EFI partition has a 779K msdos filesystem on it, which makes no sense. Once again, here is my gpart output:
gpart show
=> 40 234441568 ada0 GPT (112G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 215567272 3 freebsd-ufs (103G)
215977936 16777216 4 freebsd-swap (8.0G)
232755152 1686456 - free - (823M)
That can well be the case, if the partition was installed with "dd" of a precreated FAT32 image as FreeBSD used to do some time ago.
To fix that, assuming you have the fstab entry in place:
newfs_msdos /dev/ada0p1
mount /boot/efi
mkdir -p /boot/efi/efi/boot /boot/efi/efi/freebsd
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
umount /boot/efi
HTH,
Patrick
Ha, ok. This is interesting. I thought that I mounted the 2 partition for some reason, since the size was very close to the 512K. And who knows what weird byte calculations OSes do these days. e.g. I grew up with base-2 sizes and not using the i size notation. These days, it's a mess, especially because often the wrong units are used. Very annoying and confusing.
Quote from: tessus on July 29, 2025, 09:59:41 AMPatrick, you told me to add the following to my fstab:
/dev/ada0p1 /boot/efi msdosfs rw,noauto 2 2
I did that and when I mounted it, df showed me the following:
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 100G 15G 77G 16% /
devfs 1.0K 0B 1.0K 0% /dev
devfs 1.0K 0B 1.0K 0% /var/dhcpd/dev
devfs 1.0K 0B 1.0K 0% /var/unbound/dev
/usr/local/lib/python3.11 100G 15G 77G 16% /var/unbound/usr/local/lib/python3.11
/lib 100G 15G 77G 16% /var/unbound/lib
/dev/ada0p1 779K 644K 135K 83% /boot/efi
So something is wrong with your last comment, because I mounted the legacy bootloader with the commands you gave me.
ada0p1 is the EFI partition, the legacy boot loader is ada0p2. You cannot mount the legacy boot loader. It's not a file system.