Re: Loader needs to be updated message

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Sun, 08 Sep 2024 01:54:28 UTC
On Sun, 8 Sep 2024 02:01:02 +0100
void <void@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    <junchoon@dec.sakura.ne.jp>