Bug #10943
closedboot fail after upgrade to the latest snapshot 20201001.0050. if bios is set to efi
0%
Description
how to reproduce:
created a new virtual machine under esxi with bios set to efi
install a previous snapshot, everything work as it should.
upgrade to the latest snapshot
the system reboot and start the upgrade process,
after the upgrade you cannot log in, the WebGUI is unreachable
reboot again and it does not boot anymore
Files
Updated by Manuel Piovan about 4 years ago
i tested also the new build, 20201001.0650
after the reboot done by the upgrade process you don't lose access to the WebGUI but if you reboot again it does not boot anymore
Updated by Jim Pingle about 4 years ago
- Category set to Operating System
- Assignee set to Renato Botelho
- Target version set to 2.5.0
- Affected Version changed from 2.5.x to 2.5.0
Appears to be limited to EFI and also affects upgrades, not just new installs:
https://forum.netgate.com/topic/157298/warning-do-not-update-with-todays-1-10-snapshot
Updated by andreas vesalius about 4 years ago
As per the linked Netgate forum thread, is this only affecting those with vlans on laggs?
Updated by Jim Pingle about 4 years ago
Any lagg issue is unrelated to this. This is failing to boot at all only on EFI installs.
Any posts in that thread about lagg are irrelevant and should be in their own thread.
Updated by Jim Pingle about 4 years ago
- Status changed from New to Feedback
This is possibly related to INVARIANTS being added to the kernel which increased its size.
INVARIANTS has now been removed from the kernel, try the next new snapshot and see if it is better.
Updated by Manuel Piovan about 4 years ago
pfSense-CE-2.5.0-DEVELOPMENT-amd64-latest.iso.gz 06-Oct-2020 05:13 536447915
still not working on my esxi 7.0
upgrading fail to boot
new install fail to boot
Updated by Renato Botelho about 4 years ago
Manuel Piovan wrote:
pfSense-CE-2.5.0-DEVELOPMENT-amd64-latest.iso.gz 06-Oct-2020 05:13 536447915
still not working on my esxi 7.0
upgrading fail to boot
new install fail to boot
Hello Manuel!
Since the problem is not happening on all environments, it's hard for us to reproduce. Would it be possible for you to download this FreeBSD ISO file and check if the same error occours?
https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.2/FreeBSD-12.2-RC1-amd64-bootonly.iso
Thank you
Updated by Manuel Piovan about 4 years ago
same problem,
the installation complete successfully,
also pfsense
but when I reboot it stop like on the screenshot
Updated by Renato Botelho about 4 years ago
Manuel Piovan wrote:
same problem,
the installation complete successfully,
also pfsense
but when I reboot it stop like on the screenshot
Thanks! Can you try a final test to help us to isolate the affected versions? A recent FreeBSD 13-CURRENT snapshot
FYI, There are more at least one person reporting it on FreeBSD mailing lists
https://lists.freebsd.org/pipermail/freebsd-stable/2020-September/092736.html
Updated by Manuel Piovan about 4 years ago
- File Immagine.jpg Immagine.jpg added
- File Immagine2.jpg Immagine2.jpg added
https://forums.freebsd.org/threads/cant-boot-on-uefi.68141/
following this made my system work
shell recovery from iso
mount -t msdosfs /dev/da0p1 /mnt
efibootmgr -B 0000
efibootmgr -c -l /mnt/efi/boot/BOOTx64.efi -L "pfSense"
efibootmgr -a 0000
i need to repeat the process after every reboot
i will try freebsd 13 in a few hours, as soon as i finish my work
Updated by Manuel Piovan about 4 years ago
the installation from the iso of FreeBSD-13.0-CURRENT does not even start, it stop on the boot menu with the same error
Updated by Manuel Piovan about 4 years ago
i found a solution that worked for me for pfsense 2.5.0 and efi,
use SATA controller and remove the default SCSI controller
I don't need to mess with the efibootmgr and I can reboot as many times as I like
i still didn't found a solution for freebsd 13 but I think it's out of the scope for now
workaround... to boot freebsd 13 iso I have to go to the loader prompt and call show/efi-show and scroll down all pages and then boot... at every reboot even after installation complete
Updated by Anonymous about 4 years ago
Some additional information related to VirtualBox & EFI boot problems:
I have two boxes, both built with VB 6.x & pfSense 2.5.0, and both are EFI boot. These boxes were initial built with previous versions of both VB & pfSense 2.5.0 (don't have the exact versions I used for the builds), and have been booting fine until I had issues with the EFI boot after update, as described here; and only where able to fully update after the removal of INVARIANTS. (I tried multiple interim update revisions; thank goodness for snapshots.)
But I have also been going back to try and recreate fresh rebuilds of my boxes, and I am now finding that I can not boot both pfSense 2.5.0 and multiple versions of FreeBSD, in EFI mode under VB.
I have gone back to just testing FreeBSD with 11.4, 12.0, 12.1, 12.2-RC1, and 13.0 and none will boot with EFI enabled under VB 6.1.14. However the exact same guest configuration, changing nothing but the iso, (including keeping OS settings at BSD/FreeBSD-64), will boot Ubuntu server 20.04 with EFI enabled, with no problem.
In addition to the FreeBSD EFI boot bug noted previously there is a VB bug report of FreeBSD 12.1 not booting under VB 6.1.14: https://www.virtualbox.org/ticket/19910
From recall, VB updated their EFI firmware support, starting with version 6.1.0, that added EFI NVRAM write support, that fixed the Debian / Ubuntu EFI boot failure after initial install problems, due to not being able to write EFI nvram settings; and further changes EFI support since. (Previously when Debian based systems tried to write (non- default / standard) boot info to the EFI nvram it was ignored / lost, resulting in a no boot partition found on reboot; however other OS that used (VB) default EFI boot configs did not have issue. (I mention this because it's now possible for EFI nvram data to be written / saved in a VB guest, that were previously ignored / not saved, under previous versions of VB, such that newer OS updates are now able to write settings to EFI nvram, that were previously ignored / lost.)
In short, currently, both pfSense & FreeBSD, no longer boot in EFI mode, with the current 6.1.14 release of VirtualBox, which seems to be related to recent changes in VB's EFI support.
Updated by Anonymous about 4 years ago
- Status changed from Feedback to In Progress
Updated by Renato Botelho about 4 years ago
- Priority changed from Urgent to Normal
- Target version changed from 2.5.0 to CE-Next
It's a Virtualbox issue and not a blocker for 2.5.0. People that need to run on VirtualBox should use BIOS instead of UEFI to workaround this problem
Updated by Manuel Piovan about 4 years ago
some other reports popped out on FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244906
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250580
Updated by Christian Ullrich almost 4 years ago
Another one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866
This one has a good idea of the cause, and a two-line patch that works (on VMware in my case).
Updated by Renato Botelho almost 4 years ago
- Target version changed from CE-Next to 2.5.0
Christian Ullrich wrote:
Another one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866
This one has a good idea of the cause, and a two-line patch that works (on VMware in my case).
A commit was made on FreeBSD HEAD - https://svnweb.freebsd.org/base?view=revision&revision=368721
I'll make sure it's cherry-picked as soon as it reaches stable/12.
Updated by Renato Botelho almost 4 years ago
- Status changed from In Progress to Feedback
I've cherry-picked fix from upstream and it will be available on tomorrow's snapshot
Updated by Manuel Piovan almost 4 years ago
sorry, i didn't noticed a notification for this,
i was able to try ISO [datastore1] pfSense-CE-2.5.0-DEVELOPMENT-amd64-20210102-0250.iso
and i can confirm that the problem is solved
multiple reboot / halt and start, works like a charm
esxi 7.0 Update 1 / vm ->freebsd 12 64 bit EFI
Updated by Renato Botelho almost 4 years ago
- Status changed from Feedback to Resolved