Date: Sun, 8 Sep 2024 02:01:02 +0100 From: void <void@f-m.fm> To: freebsd-current@freebsd.org Subject: Re: Loader needs to be updated message Message-ID: <Ztz3Tq-uq7RSbclW@int21h> In-Reply-To: <20240908092302.caa9f655693f71e03ee6b030@dec.sakura.ne.jp> References: <9494862A-E445-43AC-8887-FACC84A74435.ref@yahoo.com> <9494862A-E445-43AC-8887-FACC84A74435@yahoo.com> <ZtyM5OkDRntXe1Ru@int21h> <CANCZdfoFCZJzQJJDqk8WWSUc7LKj=JjiCUsD=t=BRnYQwCEYXg@mail.gmail.com> <ZtyaOO2a3L84tAuT@int21h> <CANCZdfocFaqYLKU0zdPuHQaAK_CACad7A8CK0bm3B5=d2RVXMQ@mail.gmail.com> <20240908092302.caa9f655693f71e03ee6b030@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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. --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Ztz3Tq-uq7RSbclW>