Date: Sat, 6 Apr 2019 21:26:06 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Victor Sudakov <vas@mpeks.tomsk.su> Cc: freebsd-virtualization@freebsd.org Subject: Re: running FreePBX SNG7 Official Distro Message-ID: <201904070426.x374Q641048406@gndrsh.dnsmgr.net> In-Reply-To: <20190407031237.GA7489@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> Victor Sudakov wrote: > > > > > > I can guess that it looks for a FAT16 partition in the GPT with the type > > > > > > "efi" but the rest is a mystery for me. Why is it trying to find > > > > > > "grubx64.efi" and not the default "boot64.efi" (which is present), for > > > > > > example? > > > > > > > > > > I suspect that what ever guest you installed installed something > > > > > else someplace, either within the eft partition, or possibly in > > > > > the MBR? > > > > > > > > Do you mean to say, the guest installing something else someplace can > > > > influence the boot sequence of bhyve efi? > > > > > > The guest created all of the bits on that zvol, > > > it can influence many things. There is probably a tiny initial > > > stub that efi loads that has this bath to grubx64.efi codded in > > > it and that is what is causing this issue. > > > > It is very important to find and debug it because Oracle VirtualBox in > > UEFI mode installs and runs this guest just fine. So it must be some > > issue in bhyve itself. > > > > Here is the complete archive of everything the guest created in the EFI > > partition: http://admin.sibptus.ru/~vas/freepbx.tar.gz > > can you find those confusing bits? > > I got it! bhyve does the right thing: it tries to boot BOOTX64.EFI, but > BOOTX64.EFI makes it look for grubx64.efi. So BOOTX64.EFI must be some > kind of chain loader. And it brobably tries to read a efivariable, and if that variable is not set it defaults to grubx64.efi. This bootx64.efi is something the guest installed into the EFI partition, hence my assertion that the issue is with something the guest installed is some what valid. There are some 3rd party EFI boot managers that might help resolve this problem, or simply use the work around that I provided earlier until we can get efivars working in bhyve. > Watch the interactive session below. It does not however mean that there is > nothing to fix. As I said Oracle VirtualBox in UEFI mode installs and runs this > guest just fine. > > FS0:\> cd EFI > FS0:\EFI\> ls > Directory of: FS0:\EFI\ > 04/04/2019 15:53 <DIR> 2,048 . > 04/04/2019 15:53 <DIR> 0 .. > 04/04/2019 16:26 <DIR> 2,048 centos > 04/06/2019 04:19 <DIR> 2,048 BOOT > 0 File(s) 0 bytes > 4 Dir(s) > FS0:\EFI\> cd BOOT > FS0:\EFI\BOOT\> ls > Directory of: FS0:\EFI\BOOT\ > 04/04/2019 16:18 <DIR> 2,048 . > 04/04/2019 16:18 <DIR> 2,048 .. > 08/31/2017 21:30 1,296,176 BOOTX64.EFI > 08/31/2017 21:30 79,048 fbx64.efi > 2 File(s) 1,375,224 bytes > 2 Dir(s) > FS0:\EFI\BOOT\> BOOTX64.EFI > Failed to set MokListRT: Invalid Parameter > Failed to open \EFI\BOOT\grubx64.efi - Not Found > Failed to load image \EFI\BOOT\grubx64.efi: Not Found > start_image() returned Not Found > FS0:\EFI\BOOT\> > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904070426.x374Q641048406>