From owner-freebsd-virtualization@freebsd.org Sun Apr 7 02:37:46 2019 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AD75157599A for ; Sun, 7 Apr 2019 02:37:46 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5127F76F0E for ; Sun, 7 Apr 2019 02:37:44 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=iVhvxqccICpHrzBLIbqfIZ4G+z/PU5Zo9yH+D3/WO94=; b=pihV+ASEkpsBAlPrjaCBteVszm uM9pCpqmhT6KdmsagmcSPxALLXWfDjL2jB32oVJh21K56lgNYXO6qmIulR488RrIVEITCfawlHlzI /tskibwSKytAxky4Np6OKirjpSlgrAOiy9q4zfNCB63JQJc0d6OiETeXpFtYeBfJmJ8Y=; Received: from vas by admin.sibptus.ru with local (Exim 4.92 (FreeBSD)) (envelope-from ) id 1hCxgl-0001i1-Sz for freebsd-virtualization@freebsd.org; Sun, 07 Apr 2019 09:37:43 +0700 Date: Sun, 7 Apr 2019 09:37:43 +0700 From: Victor Sudakov To: freebsd-virtualization@freebsd.org Subject: Re: running FreePBX SNG7 Official Distro Message-ID: <20190407023743.GB99339@admin.sibptus.ru> References: <20190406085458.GA89832@admin.sibptus.ru> <201904061002.x36A2BZE044704@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <201904061002.x36A2BZE044704@gndrsh.dnsmgr.net> X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.11.4 (2019-03-13) Sender: Victor Sudakov X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 02:37:46 -0000 --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 > >=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/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.=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--