On Sun, 8 Sep 2024 02:01:02 +0100 void <v...@f-m.fm> wrote: > On Sun, Sep 08, 2024 at 09:23:02AM +0900, Tomoaki AOKI wrote: > > >Can it be in reverse? > > > >I've not read (even if it's already provided somewhere or attached) the > >vmrun.sh script, but isn't there any possibility that it somehow > >uses loader on bare-metal (regardless on /boot/ or on ESP) to kick the > >guests? > >If so, version mismatch happenes, but newer kicks older. > >But yes, usually it is not at all the problem, as newer loader codes in > >same interpreter (lua/4th) is keeping backward compatibilities, I guess. > > > >Another case is that void already stated that > > > >>>In such a case, you might need something like: > >>> > >>># cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi > >> > >>and the error is gone!!! TYVM > > > >in another mail in this thread [1]. > > I should have made it clearer, in that other case, i did > # cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootaa64.efi > as it was an arm64 context > > >This could mean that efi/freebsd/loader.efi in ESP is not called by > >the UEFI firmware and efi/BOOT/efi/bootx64.efi is used instead. > > In *this* amd64 case, neither the -current server running bhyve > nor the 13.4-stable guest have bootx64.efi present. > > /boot/efi is empty on both the server and the guest.
If not automounted, you can mount ESP manually as msdosfs there, at least for bare-metal host. IIUC, recent installation by bsdinstall creates fstab entry for it by default. -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
