running FreePBX SNG7 Official Distro

[Rodney W. Grimes]

> Rodney W. Grimes wrote:
> > > > 
> > > > You can usually use the host by doing mdconfig -f <path+to+diskimage>
> > > 
> > > Unfortunately mdconfig does not work with zvols:
> > > 
> > > root at vas:~ # mdconfig -a -f /dev/zvol/d02/vm/freepbx/disk0 
> > > mdconfig: /dev/zvol/d02/vm/freepbx/disk0 is not a regular file
> > 
> > If its a zvol cant you just do
> > gpart show /dev/zvol/d02/vm/freepbx/disk0
> > 
> > and 
> > mount -t msdosfs /dev/zvol/d02/vm/freepbx/disk0p2
> 
> No I can't if the zvol is in the "volmode=dev" mode which is the default. 
> 
> This is the default for a reason: it's no good exposing scores of always
> coming and going guest geoms to the host system. I think you can even
> get a conflict of labels or something like that one day.

So it may take a few more commands but it should be
possible to do this from the host side using host
side tools without having to boot a guest to make
these corrections.

> > > > > 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.
> > > 
> > > Can I press some key to escape to the EFI shell?
> > Not that I am aware of.
> 
> It's a major problem! There must be a well-known way to break the boot
> sequence any time and enter the EFI shell.

Agreed, hopefully those working on edk2 take note and either
chime in with what that way is, or create a bug and track
so that someone may fix this issue.

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

As I stated earlier bhyve is missing percistant efi variables,
and that is most likely the reason that VirtualBox just works
and bhyve does not.

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

Probably you well find in your VirtualBox directory a
file that is used to store efivars, that is where the
difference occurs.

> The standard procedure should be as follows:
> 
> Automated detection relies on standardized file paths to the OS
> loader, with the path varying depending on the computer architecture.
> The format of the file path is defined as
> <EFI_SYSTEM_PARTITION>/EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for
> example, the file path to the OS loader on an x86-64 system is
> /efi/BOOT/BOOTX64.EFI and efi\boot\bootaa64.efi on ARM64 architecture. 
> 
> Nothing about grub*.efi. But only bhyve is confused, VirtualBox is not.

bhyve is not really confused, it is simply missing a feature
that this guest depends on for its boot procedures.  This is
a well known miss-feature, but I do not know of anyone actively
working on fixing it.

> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> 2:5005/49 at fidonet http://vas.tomsk.ru/
-- 
Rod Grimes                                                 rgrimes at freebsd.org