Bug #15081
open
Upgrade fails due to undersized EFI filesystem
Added by Jim Pingle 12 months ago.
Updated 7 days ago.
Plus Target Version:
Plus-Next
Description
Some installations as recent as Plus 22.01 / CE 2.6.0 have EFI partitions that were created and/or populated by the old EFIFAT image method. This means that while the EFI partition is 200M, the EFI filesystem is only around 700KB. As a result, these installations are unable to upgrade to recent versions successfully as the loader cannot be updated.
This can be worked around by reformatting the EFI partition directly and copying the appropriate files back into place, as described in this forum post: https://forum.netgate.com/post/1140955
# mkdir -p /boot/efi
# mount_msdosfs /dev/msdosfs/EFISYS /boot/efi
# mkdir -p /tmp/efitmp
# cp -Rp /boot/efi/* /tmp/efitmp
# umount /boot/efi
# newfs_msdos -F 32 -c 1 -L EFISYS /dev/msdosfs/EFISYS
# mount_msdosfs /dev/msdosfs/EFISYS /boot/efi
# cp -Rp /tmp/efitmp/* /boot/efi/
There are some potential complications there. For example, the EFI filesystem may not be labeled that way, it could be /dev/gpt/EFISYS
or it may have no label at all.
Marked as Plus 24.03/CE 2.8.0 but if it can be fixed in the pfSense-boot package the fix could be picked back to 23.09.1/2.7.2.
- Related to Bug #14983: Upgrade can fail when unexpected EFI partitions are present. added
- Related to Bug #15082: Upgrade fails due to unmounted EFI filesystem added
- Related to Bug #15084: Upgrading an EFI system installed to ZFS mirror does not upgrade EFI loader on additional disks added
Do old efifat images match well-known hashes? If so, look for a partition matching the hash (maybe a bunch of different hashes for recent/upgrade-supported releases) and do the workaround on it. If none is found accept a failure pointing users to this issue. If this fits the vast majority of installations it could be acceptable.
- Has duplicate Bug #15093: Unable to install update 2.7.2 due to EFI error added
- Assignee set to Christian McDonald
- Plus Target Version changed from 24.03 to 24.07
Moving this ahead as it still might be an issue though it's unclear how many affected systems may be left in the wild. I've tried installing versions as far back as 21.02 and they all had properly sized EFI filesystems, so we also are still investigating the exact circumstances around when/how these systems may have ended up in the problem state.
- Plus Target Version changed from 24.07 to 24.08
Came across this on a production environment, can confirm the issue is resolved by following steps mentioned.
- Plus Target Version changed from 24.08 to 24.11
This is still an issue but I'm not sure what, if anything, we could do about it at this stage beyond warning like we already do. The reports of it being needed have died off, so it's possible that the few people who were stuck in that state have either reinstalled or manually fixed their installations.
Trying to upgrade to a current version with the small EFI partition does get flagged and fails before it reboots, so someone can investigate it and fix it manually using the procedure in the description above.
Updating boot code...
/usr/local/sbin/../libexec/install-boot.sh -b auto -d /tmp/be_mount.NsHa -f zfs -s gpt -u vtbd0
gpart bootcode -b /tmp/be_mount.NsHa/boot/pmbr -p /tmp/be_mount.NsHa/boot/gptzfsboot -i 2 vtbd0
partcode written to vtbd0p2
bootcode written to vtbd0
ESP /dev/vtbd0p1 mounted on /tmp/stand-test.eCQit2
Only 393KB space remaining: removing old FreeBSD boot1.efi file /efi/boot/bootx64.efi
rmdir: /tmp/stand-test.eCQit2/efi/boot: Directory not empty
Failed to update the EFI System Partition /dev/vtbd0p1
Insufficient space remaining for /tmp/be_mount.NsHa/boot/loader.efi
Run e.g "mount -t msdosfs /dev/vtbd0p1 /mnt" to inspect it for files that can be removed.
Unable to update boot code on /dev/vtbd0
- Plus Target Version changed from 24.11 to 25.01
- Target version changed from 2.8.0 to CE-Next
- Plus Target Version changed from 25.01 to Plus-Next
Also available in: Atom
PDF