| Age | Commit message (Collapse) | Author |
|---|
|
With the increase in content in initramfs, a long-overdue raise
of the default size for /boot is warranted.
Reference: https://fedoraproject.org/wiki/Changes/2GbootPartition
|
|
This ensures that there's empty space for arm-image-installer to
inject firmware blobs into images as part of preparing to install
for various single board computers.
|
|
This became necessary with 10.0.13 / after merging
https://github.com/OSInside/kiwi/pull/2535 but doesn't seem to
noticeable effects besides miisin "GRUB_ENABLE_BLSCFG=true" in
/etc/default/grub.
|
|
The Raspberry Pi 3 does not recognize a FAT filesystem marked with
the 0xef type, so until we drop support for this device, hack the
partition manually to use a legacy FAT filesystem partition type.
|
|
Now that we have a lot more stuff installed in the ESP, we need
the ESP to be bigger. This matches the size used for the desktop
disk variants.
|
|
It is hard to ensure that hardware support packages are pulled in
universally when it's splintered across different variant profiles.
To fix this and ensure Server benefits from this, unify everything
into a common profile and make everything require it.
|
|
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>
|
|
This is where the lowest level common denominator configuration
goes for most images go.
|
|
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
Janne Grunau
Andrea Bolognani
David Abdurachmanov
