From owner-freebsd-virtualization@freebsd.org Sat Apr 6 08:05:24 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 A2C961579839 for ; Sat, 6 Apr 2019 08:05:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1307B6DE3F for ; Sat, 6 Apr 2019 08:05:23 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x3685JZe043782; Sat, 6 Apr 2019 01:05:19 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x3685J6G043781; Sat, 6 Apr 2019 01:05:19 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201904060805.x3685J6G043781@gndrsh.dnsmgr.net> Subject: Re: running FreePBX SNG7 Official Distro In-Reply-To: <20190406043424.GA59075@admin.sibptus.ru> To: Victor Sudakov Date: Sat, 6 Apr 2019 01:05:19 -0700 (PDT) CC: freebsd-virtualization@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 1307B6DE3F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981,0] 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: Sat, 06 Apr 2019 08:05:25 -0000 -- 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 rgrimes@freebsd.org