This how-to is about the update of the bootcodes on FreeBSD as it's little to no documented. It only covers the GPT scheme and is intended for people with little knowledge of FreeBSD.
Edit: I wrote a script that gives the right commands to type after inspecting your system and can eventually executes them. Take a look at: https://github.com/Emrion/uploaders
Run this script and ask questions in that thread: https://forums.freebsd.org/threads/...gure-how-to-update-the-freebsd-loaders.94237/
When to update?
At each upgrade of the system whenever it's a minor or a major one.
In general, the system is compatible with the bootcodes of version-1. So personally, I do it just after the upgrade is finished.
GPT or MBR?
The command
What is/are my booting partitions?
Again,
In this example, the root disk has both booting capabilities:
Here, you see the disk-name (ada0) and the partition scheme (GPT). You have an efi partition for efi booting and a freebsd-boot partition for BIOS booting. Note the partition-name (under disk-name) you have to update and its partition-number. In the example, it's ada0p1 (partition-number is 1) & ada0p2 (partition-number is 2).
Note also the root partition type, whether it is a zfs (freebsd-zfs) or an ufs one (freebsd-ufs). It's a zfs root partition in this example.
Here we go:
Update of the efi bootcode on a GPT scheme with an installation that was made before 13.0-RELEASE (root user):
So, following the example, it's:
Important note: if you started with a 13.0-RELEASE installation, the partition where the efi loader resides is mounted on /boot/efi. In this case, you cannot mount the partition on /mnt.
So, the procedure becomes:
Very important note: if you started with FreeBSD 14, the installer has activated a EFI boot entry that refers to this loader: /efi/freebsd/loader.efi. It means the system won't boot anymore on the default /efi/boot/bootx64.efi. So, update the file bootx64.efi will have no effect. I think it's safer to update both bootcodes.
Update of the BIOS bootcode on a GPT scheme if the root partition is a freebsd-zfs type (root user):
Following the given example, it's:
Update of the BIOS bootcode on a GPT scheme if the root partition is a freebsd-ufs type (root user):
I have now to speak about the case of a zfs mirror. This is what you get with a guided installation (Auto (ZFS) with "mirror" selected). Here is an example, a mirror on two disks:
If your zfs root system is on a mirror, you have to update bootcodes on all disks that belonging to this mirror. Because in case of failure of the main disk, the others disks have to provide the booting.
In this example, there is no efi booting, just BIOS booting. So, at each upgrade I will execute:
Edit: I wrote a script that gives the right commands to type after inspecting your system and can eventually executes them. Take a look at: https://github.com/Emrion/uploaders
Run this script and ask questions in that thread: https://forums.freebsd.org/threads/...gure-how-to-update-the-freebsd-loaders.94237/
When to update?
At each upgrade of the system whenever it's a minor or a major one.
In general, the system is compatible with the bootcodes of version-1. So personally, I do it just after the upgrade is finished.
GPT or MBR?
The command
gpart show will answer to this. You will see either GPT or MBR at the first line of output. If you are on a MBR scheme, you can leave this how-to (and think about a reinstallation with GPT).What is/are my booting partitions?
Again,
gpart show will give you the answers. You can have only efi booting or only legacy BIOS booting or both.In this example, the root disk has both booting capabilities:
Code:
gpart show -p
=> 40 104857520 ada0 GPT (50G)
40 409600 ada0p1 efi (200M)
409640 1024 ada0p2 freebsd-boot (512K)
410664 984 - free - (492K)
411648 4194304 ada0p3 freebsd-swap (2.0G)
4605952 100249600 ada0p4 freebsd-zfs (48G)
104855552 2008 - free - (1.0M)Here, you see the disk-name (ada0) and the partition scheme (GPT). You have an efi partition for efi booting and a freebsd-boot partition for BIOS booting. Note the partition-name (under disk-name) you have to update and its partition-number. In the example, it's ada0p1 (partition-number is 1) & ada0p2 (partition-number is 2).
Note also the root partition type, whether it is a zfs (freebsd-zfs) or an ufs one (freebsd-ufs). It's a zfs root partition in this example.
Here we go:
Update of the efi bootcode on a GPT scheme with an installation that was made before 13.0-RELEASE (root user):
Code:
mount -t msdosfs /dev/partition-name /mnt
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
umount /mntSo, following the example, it's:
mount -t msdosfs /dev/ada0p1 /mntThis annoyance happens if the system has been installed from a 12.0 or previous RELEASE disk. It's the way loader.efi was copied into this partition. You legacy a FAT12 msdosfs that doesn't take all the available space (200 MiB).
So, you must change the file system, reformat it in Windows terms. You need first to unmount the partition:
Then:
Where partition-name is ada0p1 in the example.
DO NOT REBOOT BEFORE loader.efi IS ACTUALLY COPIED AT THE RIGHT PLACE
So, you must change the file system, reformat it in Windows terms. You need first to unmount the partition:
umount /mnt Then:
Code:
newfs_msdos -F16 /dev/partition-name
mount -t msdosfs /dev/partition-name /mnt
mkdir -p /mnt/efi/boot
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
umount /mntDO NOT REBOOT BEFORE loader.efi IS ACTUALLY COPIED AT THE RIGHT PLACE
Important note: if you started with a 13.0-RELEASE installation, the partition where the efi loader resides is mounted on /boot/efi. In this case, you cannot mount the partition on /mnt.
mount will answer "Device is busy".So, the procedure becomes:
Code:
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efiVery important note: if you started with FreeBSD 14, the installer has activated a EFI boot entry that refers to this loader: /efi/freebsd/loader.efi. It means the system won't boot anymore on the default /efi/boot/bootx64.efi. So, update the file bootx64.efi will have no effect. I think it's safer to update both bootcodes.
Code:
cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efiUpdate of the BIOS bootcode on a GPT scheme if the root partition is a freebsd-zfs type (root user):
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i partition-number disk-nameFollowing the given example, it's:
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0Update of the BIOS bootcode on a GPT scheme if the root partition is a freebsd-ufs type (root user):
gpart bootcode -b /boot/pmbr -p /boot/gptboot -i partition-number disk-nameI have now to speak about the case of a zfs mirror. This is what you get with a guided installation (Auto (ZFS) with "mirror" selected). Here is an example, a mirror on two disks:
Code:
gpart show
=> 40 3907029088 ada0 GPT (1.8T)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 3902832640 3 freebsd-zfs (1.8T)
3907028992 136 - free - (68K)
=> 40 3907029088 ada1 GPT (1.8T)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 3902832640 3 freebsd-zfs (1.8T)
3907028992 136 - free - (68K)
zpool status
pool: zroot
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p3 ONLINE 0 0 0
ada1p3 ONLINE 0 0 0If your zfs root system is on a mirror, you have to update bootcodes on all disks that belonging to this mirror. Because in case of failure of the main disk, the others disks have to provide the booting.
In this example, there is no efi booting, just BIOS booting. So, at each upgrade I will execute:
Code:
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
Last edited:
