"Boot loader is too old. Please upgrade" in console after upgrading to 2.8.0
-
Upgraded from 2.7.2 to 2.8.0 this evening. I kept getting errors when uninstalling packages (saying another instance was already running), since I like to follow best practices and uninstall all packages prior to the upgrade. Welp. So after a pre-upgrade config backup, I pulled the trigger.
I watched the log in the console, and there were hundreds of errors where it couldn't find packages (.gzip or something), but it kept on chugging along.
After a second reboot, the version in the console welcomed me with 2.8.0 and it loaded right up. Every boot I see a: "BOOT LOADER IS TOO OLD. PLEASE UPGRADE." warning flash on the screen for about 1/8 of a second. I recorded a video and took a screenshot from the video:
What is the cause of this error?
The system is stable now, but a big part of me simply wants to take a new 2.8.0 config backup and perform a clean, full install of 2.8.0 and restore the config.
Thanks for any help and answers.
-
Thanks for sharing. The more knowledge and data is valuable for everyone. I'm reading posts before attempting an upgrade but I thought I just read a post saying the full download is not available. Or at least not yet, only upgrade online is being offered.
-
@Finger79 said in "Boot loader is too old. Please upgrade" in console after upgrading to 2.8.0:
What is the cause of this error?
The files you listed are small text files.
Can you show them ?Or, (It's Friday afternoon, so allowed) console or SSH into your pfSense, go option 8, and use these commands
touch /boot/defaults/loader.conf touch /boot/device.hints touch /boot/loader.conf etc.
and now all files will have a 'today' = now time stamp, so not old anymore.
-
@HaOsLsE I think youβre misunderstanding that the Installer is the way and there isnβt a separate ISO for each version?
https://docs.netgate.com/pfsense/install/netinstaller.html -
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.
-
@SteveITS Your link is not valid anymore. It gives me a 404.
-
@Stepinsky it works for me? Maybe they were regenerating the docs or something.
-
-
@Stepinsky Oh sorry I guess I clicked on the wrong link above, on my phone. Not sure what happened there as I copy/pasted.
-
@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-boot
manually 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 hardware
I 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 list
show? -
[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....