vmware Old VMware/freebsd kernel bug again under UEFI environment?

P

piggy

I can say I never had problems in managing FreeBSD UEFI boot. I converted a lot of machines from old standard BIOS legacy boot to UEFI boot without any glitch and/or problem but this 13.1-RELEASE (i386) virtual install.

Google was my friend discovering someone had the same problem long ago with my same problem and even a bug tracker was opened and apparently solved in FreeBSD bug tracker.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250580

No problem creating and configuring the EFI partition with the powerfull loader.efi, then when it is time to load the kernel the virtual machine crash with the VMware message: "The Firmware Encountered an unexpected exception. The virtual machine cannot boot."

Reading the Dmesg printed by the virtual install before the halt, I could think there is something wrong with the machine kernel itself considering it has a Panic: exec return message prior to the VMware halt.

I also have to say I have no problem with x86_64 migrated hosts, just this i386 install.

What should I look for in the machine kernel/loader.conf or what?

I can still boot the machine becouse I just add an efi partition so I'm able to boot the machine in boot legacy (original untouched freebsd-boot partition) and UEFI mod (this like I explained do not boot).
 

Attachments

  • freebsd_vm.png
    freebsd_vm.png
    126.5 KB · Views: 92
I confirm I can reproduce this under my VMware Fusion. This has nothing to do with the files in kernel/loader.conf. Issue is happening in standalone part of FreeBSD, uefi loader. It tries to execute kernel but fails to do so, hence the panic. What you then see is just standard UEFI error.

I think PR you found is something different. Also i386 is now tier2 so you can expect lower support.
 
Thank you martin for your reply. If you say so, a problem in loader.efi, I will maybe try another, older loader.efi. The very old boot1.efi doesn't even boot the machine and the other loader_*.efi same.

If I do have a moment to spend, I will also try if this happen also under Virtualbox.

BTW, loader.efi seems really potent: in my experience of many real and virtual x86_64 machines, together with loader.env, it boots pretty much everything, even partitions on MBR disks.
 
Right now I have only my iMac at disposal, there I was not able to load uefi (bios OVMF) with i386 version of qemu. I like to debug this in qemu as I can see other control registers and see where gdt/idt is loaded.
I'll try to reproduce this there see is I can find something.

The thing is it says it's going to jump to 0x8fd000 (entry point of 32b kernel on FreeBsd 13.1) but it doesn't get there.
 
Very quick test with a i386 Virtualbox Virtual Machine! Exactly the same problem, the system stops when booting kernel exacting at the same point. Now, this loader.efi got problems with i386 like you _martin said.
 

Attachments

  • freebsd_vb.png
    freebsd_vb.png
    36.3 KB · Views: 97
Interesting issue. I'll try to dig deeper, hopefully tonight. Btw. is this the very same version you're running on vmware ?
 
It is another machine, then both are i386, one the one on VMware is 13-RELEASE, the one on VirtualBox is 13.1-RELEASE.
 
Last night I tried to launch it in qemu-i386. I had 0 success launching uefi shell, tried few bios images, even the VMware ones. It was always stuck in the "guest has not initialized display(yet)". No matter how much I tried it just didn't work. It works fine on 64b version.
While that phase has nothing to do with the OS yet it was important to me to have it running there.

Debugging UEFI is pain, especially this part as I can't use even printf at this stage and have no symbols (basically need to do a RE on it).
The little I did using vmware+gdb I noticed it fails in internal UEFI API function. Because exec address has no valid data yet I'd assume issue is hit during copy and/or alignment of the kernel. Actually adm64 had issue on hyperv which made me thing of a test worth doing - trying this on hyperv too.
In boot prompt I tried to unload all and load only kernel to see if maybe that's relevant. It was not, issue occurred anyway.

I'm still curious to see if I can dig up more.

But as it is reproducible you may get better chance of opening PR though not sure how much support you get on i386.
 
I don't have much time now but I did manage to run it in qemu. I want to share this partial result.
Why didn't I think to look for uefi firmware in "our" ports, instead I was googling around. For random googlers I'm running VM this way:
Code: 
qemu-system-i386 -s -m 2048 -bios QEMU_UEFI-i386.fd -debugcon file:debug.log -global isa-debugcon.iobase=0x402 \
-serial file:serial.log \
-hda FreeBSD-13.1-RELEASE-i386.qcow2
Bios is coming from sysutils/edk2.

I managed to capture the exception:
Code: 
!!!! IA32 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
EIP  - 000A009D, CS  - 00000010, EFLAGS - 00000087
EAX  - 7FEDC857, ECX - 0000000E, EDX - 7FEBE4D4, EBX - 7FEBE4D4
ESP  - 7FEBF25C, EBP - 7FEBF298, ESI - 80000007, EDI - 7F347010
DS   - 00000008, ES  - 00000008, FS  - 00000008, GS  - 00000008, SS - 00000008
CR0  - 40000033, CR2 - 00000000, CR3 - 00000000, CR4 - 00000640
DR0  - 00000000, DR1 - 00000000, DR2 - 00000000, DR3 - 00000000
DR6  - FFFF0FF0, DR7 - 00000400
GDTR - 7FC7F000 00000047, IDTR - 7F88D010 000007FF
LDTR - 00000000, TR - 00000000
FXSAVE_STATE - 7FEBEFA0
Where EIP points to a bogus code. Even more so though, the address 0x8fd000 does have all 0xffffff.. So also invalid opcodes.
 
You must log in or register to reply here.
Back
Top