running FreePBX SNG7 Official Distro

Rodney W. Grimes freebsd-rwg at gndrsh.dnsmgr.net
Sat Apr 6 08:05:25 UTC 2019


-- Start of PGP signed section.
> Rodney W. Grimes wrote:
> 
> [dd]
> 
> > > 
> > > root at mfsbsd:~ # find /mnt/ -name grubx64.efi
> > > /mnt/EFI/centos/grubx64.efi
> > > 
> > > Who is to blame, bhyve or FreePBX's installer?
> > > 
> > > How can I tell bhyve's UEFI loader to look for grubx64.efi in a
> > > different place? Or look for a different loader?
> > > 
> > > Who says that the image to load should be "\EFI\BOOT\grubx64.efi" and
> > > not "\EFI\BOOT\BOOTX64.EFI" for example?
> > 
> > I can not quickly answer that, but lets try the short quick fix
> > and simply copy this file to the right place and see if that
> > gets you up and running. 
> 
> Yes, copying grubx64.efi to "\EFI\BOOT\" does get the guest up and
> running (I used mfsbsd from a different VM to manipulate the EFI
> partition).

You can usually use the host by doing
mdconfig -f <path+to+diskimage>
gpart show md0			# Assuming mdconfig was unit 0
mount -t msdosfs /dev/md0p<n> /mnt  #The n comes from gpart, you want the efi partition

Now you can manipulate /mnt/ all you want
umount /mnt
mdconfig -d -u 0		# Assuming mdconfig was unit 0

> Moreover, I waited (for a long time!) for the EFI interactive shell
> prompt and with a few commands:

Yes, the timeout is very long, and I do not know that we
document anyplace that if you wait long enough at a failed
boot you do get a EFI shell prompt eventually.

> 
>  Shell> fs0
>  FS0:\> cd \EFI\centos
>  FS0:\EFI\centos\> grubx64.efi       
> 
> I also managed to boot the guest OS all right.
> 
> But naturally, the latter fix worked till next reboot only, I don't know
> how to save the new EFI setup in the guest's configuration.

My recommedation at this time would be to simply copy grubx64.efi
to the right place and leave it there so that it just boots without
any other change.

> 
> The hardware UFI BIOSes I've seen so far (not many, I must admit)
> permitted me to save which efi binary I would prefer to boot next time.

That is done with an efivar, as it stands right now bhyve efi has
no persistant variable storage, a feature that needs to be implemented.

> > That would also tell us that we have
> > what is actually a common efi system failure problem in that
> > stuff looks in the wrong place.
> 
> It seems so.
> 
> >  I have read many an install
> > instruction that just says copy this file to these too places
> > as some bioses look for it in one place and others look for it
> > someplace else.
> 
> I would very much appreciate a link to some such instruction about
> uefi-edk2-bhyve: namely how and where it looks for what on boot, and if I
> can create a menu for example, or change its startup procedure.

I do not know where that information is, others may be able to
fill in more details.

> 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?

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the freebsd-virtualization mailing list