On Mi, 01.07.20 18:31, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
> > One problem with sd-boot is that the kernels must stay on
the ESP, which
> > can be a problem for dual-boot installs (where Fedora has to run with
> > the existing ESP and can't just create one which is big enouth).
>
> Nah, that's not true. Hasn't been for quite a while.
>
> sd-boot checks for kernels in the ESP first, and then on a second
> partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
> partition is simply a partition with type UUID
> bc13c2ff-59e6-4262-a352-b275fd6f7172.
Ah, this is news to me. XBOOTLDR must be formated with a filesystem the
uefi firmware can read (i.e. vfat in practice) I assume?
The spec doesn't strictly mandate that in the general case. I think it
would still be wise to stick to vfat, given that this means all kind
of firmware can easily read it, but if your boot loader/firmware can
read something else that's OK too.
> sd-boot is uefi only, but it should work fine with any arch that
is
> supported by uefi.
Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi
doesn't exist ...).
Hmm, I know that people build it on ARM, I guess we could enable that
in Fedora too. I am not an ARM pro myself, not sure what happens there
right now.
Upstream sd-boot has support for UEFI ia32, x64, arm and aa64.
Lennart
--
Lennart Poettering, Berlin