Date: Mon, 22 Mar 2021 19:27:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 250580] VMware UEFI guests crash in virtual hardware after r366691 Message-ID: <bug-250580-227-6Wnv9CcsDr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-250580-227@https.bugs.freebsd.org/bugzilla/> References: <bug-250580-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250580 ruben@verweg.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ruben@verweg.com --- Comment #22 from ruben@verweg.com --- Chiming in on a similar observation (that removing the VM's nvram file alleviates the issue) Installed FreeBSD 11.2 with Auto ZFS in vmware fusion 12.1.0 (as RAID1) Upgraded it to 12.2. gpart bootcode was used to update both boot1.efifat and gptzfsboot UEFI boot doesn't work anymore, unless when the system is reset from the bo= ot loader and choose "boot from file" chosing BOOTx64.efi from either EFI partition.=20 Creating it as a boot entry using the VMWare EFI setup screen made no difference with auto booting, but it would works when dropping again in the vmware EFI firmware and select one of the entries that where created. It not, any automated (re)boot lets VMWare stop with "The firmware encounte= red an unexpected exception." Removing the nvram file lets the system boot normally once. After that it will run into the "The firmware encountered an unexpected exception" again. However, replacing BOOTx64.efi with /boot/loader.efi instead of /boot/boot1= .efi lets the system reliably reboot into multi user mode.=20 keeping BOOTx64.efi as boot1.efi and creating boot entries for \EFISYS\FreeBSD\loader.efi doesn't work. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-250580-227-6Wnv9CcsDr>