Date: Sun, 7 Apr 2019 09:37:43 +0700 From: Victor Sudakov <vas@mpeks.tomsk.su> To: freebsd-virtualization@freebsd.org Subject: Re: running FreePBX SNG7 Official Distro Message-ID: <20190407023743.GB99339@admin.sibptus.ru> In-Reply-To: <201904061002.x36A2BZE044704@gndrsh.dnsmgr.net> References: <20190406085458.GA89832@admin.sibptus.ru> <201904061002.x36A2BZE044704@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Rodney W. Grimes wrote: > > >=20 > > > You can usually use the host by doing mdconfig -f <path+to+diskimage> > >=20 > > Unfortunately mdconfig does not work with zvols: > >=20 > > root@vas:~ # mdconfig -a -f /dev/zvol/d02/vm/freepbx/disk0=20 > > mdconfig: /dev/zvol/d02/vm/freepbx/disk0 is not a regular file >=20 > If its a zvol cant you just do > gpart show /dev/zvol/d02/vm/freepbx/disk0 >=20 > and=20 > mount -t msdosfs /dev/zvol/d02/vm/freepbx/disk0p2 No I can't if the zvol is in the "volmode=3Ddev" mode which is the default.= =20 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: > > >=20 > > > 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. > >=20 > > 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? > > >=20 > > > I suspect that what ever guest you installed installed something > > > else someplace, either within the eft partition, or possibly in > > > the MBR? > >=20 > > Do you mean to say, the guest installing something else someplace can > > influence the boot sequence of bhyve efi? >=20 > 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_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.=20 Nothing about grub*.efi. But only bhyve is confused, VirtualBox is not. --=20 Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ --l76fUT7nc3MelDdI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJcqWJ3AAoJEA2k8lmbXsY0g3kH/2E54ixKEYsGZ+6mN+kETYAV F1OV5q9e17lDM+S0mGXX4RqEDuEn5YfFF4UN8Y8KVjroWPe2Gzi/Q/EAXi0aD2Pl Yq9ehits9OdVdqWbFR1O0EP1GfQ6+m2aC+ZegsTBQbcNe1uE5OSjV26DAVCsfnYZ wWikSrndrfHRmO1ZAjeKmLx6r2KTxORk84lAIljvAKJcocCxRP1UHV6IihpNOAce aLsILy8lg83/kcTH7itt3pyNWsWOOOK/Isl1/C0I8sCwRZ4GyxirLfKYjepWTLiD uPgJ9Lkp7T42jr+fN8gho/UzRJv2GQdint3ZiQw9Kvc4uDuP4ecb+wgf5BCBqHE= =nAUV -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190407023743.GB99339>