"Boot loader is too old. Please upgrade" in console after upgrading to 2.8.0
-
@jimp said in "Boot loader is too old. Please upgrade" in console after upgrading to 2.8.0:
The upgrade process tries to update the boot loader but there are some edge cases where it can't do so properly/fully.
One thing to check is if you have multiple disks in the system. If there are multiple disks and pfSense is installed on both of them it could be using the boot loader from one disk but the kernel from a different disk.
The fix in that case is to wipe the old/unused disk and/or make sure the EFI/BIOS is booting from the correct disk.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/multiple-disks.html
You can manually update the loader as well but doing so varies based on your install specifics. For example if it's GPT or MBR, BIOS or EFI, if it has an older or newer style EFI partition, and more.
Just one disk, an SSD. This is a simple baremetal install. Pretty sure it's GPT and EFI. Secure boot is disabled until FreeBSD supports it or pfSense rebases off Linux.
Only thing I can think of is I'm using GELI for FDE, but I don't believe it was a problem upgrading from 2.6.x to 2.7.0 and then to 2.7.1 and 2.7.2.
-
That's almost certainly it. The code to update the bootloader is new, it wouldn't have run at previous updates.
-
@stephenw10 said in "Boot loader is too old. Please upgrade" in console after upgrading to 2.8.0:
That's almost certainly it. The code to update the bootloader is new, it wouldn't have run at previous updates.
How do I fix this without a full reinstall?
-
If you try running
install-bootmanually what error is returned?[2.8.0-RELEASE][admin@cedev-2.stevew.lan]/root: install-boot System Configuration Architecture: amd64 Boot Devices: /dev/ada0 /dev/ada1 Boot Method: uefi Filesystem: zfs Platform: QEMU Guest Proced with updating boot code? [y/N]: y Updating boot code... /usr/local/sbin/../libexec/install-boot.sh -b auto -f zfs -s gpt -u ada1 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1 partcode written to ada1p2 bootcode written to ada1 ESP /dev/ada1p1 mounted on /tmp/stand-test.7soQsf 263440KB space remaining on ESP: renaming old bootx64.efi file /efi/boot/bootx64.efi /efi/boot/bootx64-old.efi 263440KB space remaining on ESP: renaming old loader.efi file /etc/freebsd/loader.efi /etc/freebsd/loader-old.efi Copying loader.efi to /EFI/freebsd on ESP Creating UEFI boot entry for FreeBSD Marking UEFI boot entry 0008 active Copying bootx64.efi to /efi/boot on ESP Unmounting and cleaning up temporary mount point Finished updating ESP /usr/local/sbin/../libexec/install-boot.sh -b auto -f zfs -s gpt -u ada0 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0 partcode written to ada0p2 bootcode written to ada0 ESP /dev/ada0p1 mounted on /tmp/stand-test.MURwDh 263472KB space remaining on ESP: renaming old bootx64.efi file /efi/boot/bootx64.efi /efi/boot/bootx64-old.efi 263472KB space remaining on ESP: renaming old loader.efi file /etc/freebsd/loader.efi /etc/freebsd/loader-old.efi Copying loader.efi to /EFI/freebsd on ESP Existing UEFI FreeBSD boot entry found: not creating a new one Copying bootx64.efi to /efi/boot on ESP Unmounting and cleaning up temporary mount point Finished updating ESP Done. -
System Configuration Architecture: amd64 Boot Devices: Unable to locate boot devices Boot Method: uefi Filesystem: zfs Platform: unknown hardwareI said "no" when asked to proceed, since I'm not prepared for downtime in case it fails. This is currently my only production router/firewall.
-
Ok interesting, It can't do anything if it doesn't see the boot device anyway.
How does the encrypted boot disk appear in /dev or in the boot logs?
The correct fix here would be to fix the bootloader updater so it knows about encrypted drives. We'll have to look into how difficult that might be.
-
@stephenw10 said in "Boot loader is too old. Please upgrade" in console after upgrading to 2.8.0:
Ok interesting, It can't do anything if it doesn't see the boot device anyway.
How does the encrypted boot disk appear in /dev or in the boot logs?
The correct fix here would be to fix the bootloader updater so it knows about encrypted drives. We'll have to look into how difficult that might be.
[2.8.0-RELEASE][admin@pfSense.home.internal]/dev: ls -l total 3 crw-rw-r-- 1 root operator 0x2f Jun 15 00:18 acpi crw-r----- 1 root operator 0x73 Jun 15 00:18 ada0 crw-r----- 1 root operator 0x74 Jun 15 00:18 ada0p1 crw-r----- 1 root operator 0x75 Jun 15 00:18 ada0p2 crw-r----- 1 root operator 0x78 Jun 15 00:18 ada0p2.eli crw-rw-r-- 1 root operator 0x31 Jun 15 00:18 apm crw-rw---- 1 root operator 0x30 Jun 15 00:18 apmctl crw------- 1 root wheel 0x39 Jun 15 00:18 atkbd0(That's obviously a partial output of ls-l. There's a couple more pages, but that's all for ada*)
Do either of these help answer your question?
-
Yes, that the disks still appear as adaX but one partition is different. What does
gpart listshow? -
[2.8.0-RELEASE][admin@pfSense.home.internal]/root: gpart list Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 250069639 first: 40 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 272629760 (260M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r1w1e2 efimedia: HD(1,GPT,[uuid1],0x28,0x82000) rawuuid: [uuid1] rawtype: [is this sensitive?] label: efiboot0 length: 272629760 offset: 20480 type: efi index: 1 end: 532519 start: 40 2. Name: ada0p2 Mediasize: 127761645568 (119G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 273678336 Mode: r1w1e1 efimedia: HD(2,GPT,[uuid2],0x82800,0xedf9800) rawuuid: [uuid2] rawtype: [is this sensitive?] label: zfs0 length: 127761645568 offset: 273678336 type: freebsd-zfs index: 2 end: 250068991 start: 534528 Consumers: 1. Name: ada0 Mediasize: 128035676160 (119G) Sectorsize: 512 Mode: r2w2e5 -
Ah, OK. It doesn't expose the boot partition via GEOM. That's why the script shows it can't find it.
OK lets see what we can do here....
