U-Boot does not support XFS and this causes significant issues
when trying to boot Fedora Server on single board computers.
Resolve this by using ext4 here, as all U-Boot variants generally
support this.
Turns out that different boards needs different values, so
hardcoding a specific one here is not a good idea. Luckily,
Linux can usually figure things out on its own and automatically
provide a working serial console.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Most of the changes are self-explanatory and just follow what's
already happening for existing architectures.
Two things are worth pointing out:
* we need to use shim-unsigned instead of shim-signed because
riscv64 is not fully integrated into Fedora yet and so we
can't do Secure Boot signing for the time being;
* we use ext4 as bootfilesystem since in most cases the
underlying firmware is going to be U-Boot, which needs to be
able to load the board's DTB from /boot and doesn't support
XFS.
Signed-off-by: David Abdurachmanov <davidlt@rivosinc.com>
While cloud images can usually be booted without any issues and
for workstation installs we want a visually polished experience,
in the case of server installs on real hardware it is generally
expected to have convenient access to the bootloader menu for
troubleshooting purposes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Many of the older supported AArch64 systems (particularly single
board computers) require a legacy MBR (Master Boot Record) type
partitioning to successfully boot.
This is loosely based on the Server kickstart and ELN descriptions.
This covers both the disk image for running on ARM hardware as well
as the VM image for running on various hypervisor platforms.
Neal Gompa