Re: running FreePBX SNG7 Official Distro
Subbsd wrote: > On Sun, Apr 7, 2019 at 11:15 AM Victor Sudakov wrote: > > > I'll look into the VirtualBox directory tomorrow and report here. I was > > under the impression that efivars are stored in a configuration file in > > the EFI partition but I was probably wrong, they are kept in NVRAM > > somewhere, like BIOS settings, and not on a disk. > > I just wanted to confirm that this is indeed an EVIVARS problem, > because through CBSD (which uses Refind [1]) FreePBX 1805-2 > boots without any problems. Therefore, as Rodney said, you can try > using a third-party EFI boot manager. > And just wait until someone finds the time to add support for UEFI > VARS in bhyve. > > [1] - http://www.rodsbooks.com/refind/ Kudos to the FreeBSD team! I've just discovered that when you install FreeBSD in UEFI mode, the installer creates a /efi/boot/startup.nsh on the efi partition. So FreeBSD would boot without any problems in VirtualBox with EFI, no need for persistent efi variables. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
Victor Sudakov wrote: > > > > I'll look into the VirtualBox directory tomorrow and report here. > > > > > > I searched through my disk and was unable to find a persistant efivars > > > storage in my VirtualBox 6.0 installation. > > > > > > A Google search reveals some articles (rather dated I must admit) > > > stating that VirtualBox does not support NVRAM emulation for storing efi > > > variables: > > > > > > https://www.virtualbox.org/ticket/14279 > > > https://forums.virtualbox.org/viewtopic.php?t=61970 > > > > My quick search turns up: > > https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/DevEFI.cpp > > My quick search turns up that it's there in the code but it is not > used, or it is not enabled by default, whatever (it's written in > https://forums.virtualbox.org/viewtopic.php?p=402022=02333b87a8a2bba99383449fc08ca317#p402022 > ) > A fairly recent note: https://www.centos.org/forums/viewtopic.php?p=278745=e52bd17e42d2530f496749054b0cc174#p278745 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
Rodney W. Grimes wrote: > > > > > > > > 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. > > > > > > > > Probably you well find in your VirtualBox directory a > > > > file that is used to store efivars, that is where the > > > > > > I'll look into the VirtualBox directory tomorrow and report here. > > > > I searched through my disk and was unable to find a persistant efivars > > storage in my VirtualBox 6.0 installation. > > > > A Google search reveals some articles (rather dated I must admit) > > stating that VirtualBox does not support NVRAM emulation for storing efi > > variables: > > > > https://www.virtualbox.org/ticket/14279 > > https://forums.virtualbox.org/viewtopic.php?t=61970 > > My quick search turns up: > https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/DevEFI.cpp My quick search turns up that it's there in the code but it is not used, or it is not enabled by default, whatever (it's written in https://forums.virtualbox.org/viewtopic.php?p=402022=02333b87a8a2bba99383449fc08ca317#p402022 ) > > aka source code thet implements efivars stored in nvram. Anyway, I could not find a file in my virtualbox directory which would look like a storage with NVRAM data. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
> Victor Sudakov wrote: > > > > > > 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. > > > > > > Probably you well find in your VirtualBox directory a > > > file that is used to store efivars, that is where the > > > > I'll look into the VirtualBox directory tomorrow and report here. > > I searched through my disk and was unable to find a persistant efivars > storage in my VirtualBox 6.0 installation. > > A Google search reveals some articles (rather dated I must admit) > stating that VirtualBox does not support NVRAM emulation for storing efi > variables: > > https://www.virtualbox.org/ticket/14279 > https://forums.virtualbox.org/viewtopic.php?t=61970 My quick search turns up: https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/DevEFI.cpp aka source code thet implements efivars stored in nvram. > they recommend using startup.nsh instead. I wonder if bhyve's efi > implementation supports startup.nsh. I believe that is how the alternate boot selector someone pointed at gets hooked in. > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ -- Rod Grimes rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
Victor Sudakov wrote: > > > > 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. > > > > Probably you well find in your VirtualBox directory a > > file that is used to store efivars, that is where the > > I'll look into the VirtualBox directory tomorrow and report here. I searched through my disk and was unable to find a persistant efivars storage in my VirtualBox 6.0 installation. A Google search reveals some articles (rather dated I must admit) stating that VirtualBox does not support NVRAM emulation for storing efi variables: https://www.virtualbox.org/ticket/14279 https://forums.virtualbox.org/viewtopic.php?t=61970 they recommend using startup.nsh instead. I wonder if bhyve's efi implementation supports startup.nsh. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
> On Sun, Apr 7, 2019 at 11:15 AM Victor Sudakov wrote: > > > I'll look into the VirtualBox directory tomorrow and report here. I was > > under the impression that efivars are stored in a configuration file in > > the EFI partition but I was probably wrong, they are kept in NVRAM > > somewhere, like BIOS settings, and not on a disk. > > > > -- > > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > > 2:5005/49@fidonet http://vas.tomsk.ru/ > > I just wanted to confirm that this is indeed an EVIVARS problem, > because through CBSD (which uses Refind [1]) FreePBX 1805-2 > boots without any problems. Therefore, as Rodney said, you can try > using a third-party EFI boot manager. > And just wait until someone finds the time to add support for UEFI > VARS in bhyve. Thank you for the analysis and confirmation! > [1] - http://www.rodsbooks.com/refind/ -- Rod Grimes rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
On Sun, Apr 7, 2019 at 11:15 AM Victor Sudakov wrote: > I'll look into the VirtualBox directory tomorrow and report here. I was > under the impression that efivars are stored in a configuration file in > the EFI partition but I was probably wrong, they are kept in NVRAM > somewhere, like BIOS settings, and not on a disk. > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ I just wanted to confirm that this is indeed an EVIVARS problem, because through CBSD (which uses Refind [1]) FreePBX 1805-2 boots without any problems. Therefore, as Rodney said, you can try using a third-party EFI boot manager. And just wait until someone finds the time to add support for UEFI VARS in bhyve. [1] - http://www.rodsbooks.com/refind/ ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
Rodney W. Grimes 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. Do you think the guest OS installer set some efi variable during the installation process, which bhyve did not save? That would explain a lot. > > > > > > 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. Would it be useful to create a PR in the FreeBSD bugtracker with a feature request? > > > > 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. > > Probably you well find in your VirtualBox directory a > file that is used to store efivars, that is where the I'll look into the VirtualBox directory tomorrow and report here. I was under the impression that efivars are stored in a configuration file in the EFI partition but I was probably wrong, they are kept in NVRAM somewhere, like BIOS settings, and not on a disk. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
Rodney W. Grimes wrote: > > > > > > > > > > You can usually use the host by doing mdconfig -f > > > > > > > > Unfortunately mdconfig does not work with zvols: > > > > > > > > root@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. I'm not aware of such commands. If anyone knows them please share with us. Moreover, I already asked a similar question in February under the topic "mounting/exporting/importing a zfs volume" and nobody gave a recipe. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
> 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 2,048 . > 04/04/2019 15:53 0 .. > 04/04/2019 16:26 2,048 centos > 04/06/2019 04:19 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 2,048 . > 04/04/2019 16:18 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 rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
> Rodney W. Grimes wrote: > > > > > > > > You can usually use the host by doing mdconfig -f > > > > > > Unfortunately mdconfig does not work with zvols: > > > > > > root@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/BOOT/BOOT.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@fidonet http://vas.tomsk.ru/ -- Rod Grimes rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
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. 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 2,048 . 04/04/2019 15:53 0 .. 04/04/2019 16:26 2,048 centos 04/06/2019 04:19 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 2,048 . 04/04/2019 16:18 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/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
Rodney W. Grimes wrote: > > > > > > You can usually use the host by doing mdconfig -f > > > > Unfortunately mdconfig does not work with zvols: > > > > root@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. > > > > 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. > > > > 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? 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/BOOT/BOOT.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. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
> Rodney W. Grimes wrote: > > > > > > [dd] > > > > > > > > > > > > > root@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 > > Unfortunately mdconfig does not work with zvols: > > root@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 > > > > 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. > > > 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. > > That's what I have done for now. > > > > > > > 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. > > I see. > > [dd] > > > > > > 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. -- Rod Grimes rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
Rodney W. Grimes wrote: > > > > [dd] > > > > > > > > > > root@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 Unfortunately mdconfig does not work with zvols: root@vas:~ # mdconfig -a -f /dev/zvol/d02/vm/freepbx/disk0 mdconfig: /dev/zvol/d02/vm/freepbx/disk0 is not a regular file > > 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? > > 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. That's what I have done for now. > > > > 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. I see. [dd] > > > 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? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
-- Start of PGP signed section. > Rodney W. Grimes wrote: > > [dd] > > > > > > > root@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 gpart show md0 # Assuming mdconfig was unit 0 mount -t msdosfs /dev/md0p /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 rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
Rodney W. Grimes wrote: [dd] > > > > root@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). Moreover, I waited (for a long time!) for the EFI interactive shell prompt and with a few commands: 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. 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 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 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? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: running FreePBX SNG7 Official Distro
-- Start of PGP signed section. > Victor Sudakov wrote: > > > > Has anyone tried to run FreePBX under bhyve? That's what I get trying to > > start the vm after a successful automatic install from the ISO image: > > > > Boot Failed. EFI DVD/CDROM > > 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 > > Boot Failed. EFI Misc Device > > Below are the partitions the automatic installer has created (looking at > them from another vm): > > root@mfsbsd:~ # gpart show vtbd1 > => 34 41942973 vtbd1 GPT (20G) > 34 2014 - free - (1.0M) > 2048186368 1 efi (91M) > 188416 4096000 2 ms-basic-data (2.0G) >4284416 37654528 3 linux-lvm (18G) > 41938944 4063 - free - (2.0M) > > If I "mount_msdosfs /dev/vtbd1p1 /mnt/" I see that grubx64.efi is not > where bhyve expects to find it: > > root@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. 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. 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. -- Rod Grimes rgri...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: running FreePBX SNG7 Official Distro
Victor Sudakov wrote: > > Has anyone tried to run FreePBX under bhyve? That's what I get trying to > start the vm after a successful automatic install from the ISO image: > > Boot Failed. EFI DVD/CDROM > 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 > Boot Failed. EFI Misc Device Below are the partitions the automatic installer has created (looking at them from another vm): root@mfsbsd:~ # gpart show vtbd1 => 34 41942973 vtbd1 GPT (20G) 34 2014 - free - (1.0M) 2048186368 1 efi (91M) 188416 4096000 2 ms-basic-data (2.0G) 4284416 37654528 3 linux-lvm (18G) 41938944 4063 - free - (2.0M) If I "mount_msdosfs /dev/vtbd1p1 /mnt/" I see that grubx64.efi is not where bhyve expects to find it: root@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? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
running FreePBX SNG7 Official Distro
Dear Colleagues, Has anyone tried to run FreePBX under bhyve? That's what I get trying to start the vm after a successful automatic install from the ISO image: Boot Failed. EFI DVD/CDROM 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 Boot Failed. EFI Misc Device . The vm config: uefi="yes" cpu=1 memory=2G network0_type="virtio-net" network0_switch="main" disk0_type="virtio-blk" disk0_name="disk0" disk0_dev="zvol" graphics="yes" graphics_wait="no" graphics_res="1280x720" graphics_port="5909" graphics_listen="192.168.4.1" xhci_mouse="yes" uuid="4c1871cb-56f1-11e9-bdbf-5404a6b49a66" network0_mac="58:9c:fc:0b:85:76" -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
