Just a tiny wrapper that makes things more convenient by
automatically figuring out most of the options that need to be
passed to kiwi.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
For whatever reason, serial output is really slow on P550, to
the point where drawing the grub menu takes an annoyingly long
amount of time and really gets in the way.
To avoid that issue, use the countdown timeout instead. This
still gives users a chance to enter the full menu if they need
to while making things a lot faster for regular boots.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We keep hitting this situation on P550 where
systemd-vconsole-setup runs after initial-setup has already
been started. This causes virtual consoles to be re-initialized,
and as a consequence initial-setup stops accepting input and
becomes effectively stuck. This doesn't seem to be a problem on
other hardware, e.g. VF2.
Generally speaking having initial-setup run during the first
boot provides a good user experience and matches what other
architectures are doing, so we want to keep doing it, but the
issue mentioned above makes it a no-go for P550.
Until we've figured out how to prevent this from happening,
don't enable initial-setup and keep the default root password
around so that the machine can still be logged into.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The vendor firmware for P550 doesn't know how to pick up the
DTB automatically from /boot, and we've been having trouble
getting that combination to work correctly anyway.
While we work on a more standard solution, get things to boot
by telling grub where the DTB is so that it will automatically
add a "devicetree" command to all boot entries.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
P550 needs a custom kernel, which is only available through a
special repo. Since repos are configured very eary in the image
building process, before profiles are considered, we need a
whole separate kiwi file to make things work.
This unfortunately requires a bit of duplication, but thankfully
we can keep the P550 part quite minimal since we don't need to
worry about things like non-riscv64 variants of the various
profiles, or cloud images.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The Fedora RISC-V maintainers have a strong preference for this
filesystem over the lvm+xfs combo used by other server images.
Additionally, use ext4 for the boot filesystem. This not only
matches what is done for other btrfs-using images, but is
particularly useful on riscv64 because u-boot, which is used as
the firmware on most hardware, doesn't support booting off xfs.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Samyak Jain <samyak.jn11@gmail.com>
(cherry picked from commit 8203a65b0c0e347efb0de9b56a1410d77f2f6486)
We want to build Fedora 41 images, so we need to change these
values back.
Signed-off-by: Andrea Bolognani <abologna@redhat.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>
Disk images are usually flashed to media which is much larger
than they are, and all that additional space goes unused until
the user intervenes.
Configure things so that systemd-repart, which runs by default,
automatically takes care of resizing the root partition.
systemd-growfs, which also runs by default, will subsequently
take care of resizing the filesystem to fill the newly-enlarged
partition.
Note that we don't do this for cloud images, since in that
case cloud-init takes care of resizing the root filesystem and
the underlying partition together with all the other setup
tasks.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We only really need i686/x86_64 libraries, and executables which do not exist
(or do not work equivalently) on the arm64 host system.
In particular, removing libexec avoids situations where random dbus services
are started under emulation for no reason.
We're currently shipping GTK2/3 libs in the rootfs. While we're doing
that, let's also install XIM support, which actually works through X11
passthrough with muvm. This should generally make legacy GTK x86_64
apps have input method support the old-fashioned way.
Modern apps should use the Wayland input method protocol stuff, which is
already built into GTK3/GTK4 and should not require any extra shared
libraries for FEX. For muvm, that will work once we have Wayland
passthrough.
Per #112, excluding group specs just does not work in Kiwi at
present. For LXQt this is especially a problem because it means
the image fails to compose. The exclusion of m17n* *does* work
as it's a package spec, but because the exclusion of the
input-methods group does not work, dnf wants to install
ibus-typing-booster (part of input-methods), which requires
m17n-lib, and these conflicting requirements cause it to blow up.
So at least until the problem of not being able to exclude
groups is resolved, we should drop these.
Arguably, we should permanently stop excluding input-methods, at
least. Space constraints aren't as huge of a deal these days as
they used to be, on the whole; lots of folks have decent bandwidth,
lots of disk space, and large USB sticks. Input methods are
critical for CJK users; leaving them off the image makes it more or
less useless for them, which is a significant impairment. (Unless,
that is, input methods don't work properly in LXQt even if included
- I haven't tested this).
Signed-off-by: Adam Williamson <awilliam@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.
Many of the older supported AArch64 systems (particularly single
board computers) require a legacy MBR (Master Boot Record) type
partitioning to successfully boot.
Group exclusions do not seem to work anymore with DNF5, so explicitly
filter out unwanted packages. Additionally, add missing unwanted
packages from the kickstarts and refactor it to apply to both
KDE Desktop and KDE Mobile profiles.
As it currently stands, this doubles the size of the live ISOs,
which is completely unacceptable.
We will need to make the switch eventually, but we need to figure
out how to compress better first.
This reverts commit 1457e97008f15064dcc30aaca9977ffa1ec66572.
EROFS is newer, more performant filesystem that emphasizes speed
and integrity over SquashFS. It is also much better maintained and
friendlier for flash-based storage that live media is typically
run from these days.
ibus: This is an input method, which is a user choice. It doesn't make
sense to ship some input method libs and not others. These libs
typically communicate with the main IM daemon over UNIX sockets, so this
won't work anyway without additional work. (This might cause some
spurious errors as the guest tries to load the nonexistent IM, but we
can ignore them since it wouldn't work anyway).
xdg-desktop-portal: This is just data and executables, no libraries, so
it makes no sense for FEX.
glibc-langpack-en, kbd-misc: Only needed for kiwi, add a comment
zenity: Used by Steam but it's just a binary, so this should be an
aarch64 dependency, not run emulated.
llvm 14 & 15: I don't think there's a good reason to ship these? Any
reasonable binary-packaged app shouldn't be depending on specific LLVM
versions like this. Let's keep llvm18 & 19 since 18 is used by our Mesa
builds.
sudo & rsync: Binaries only (and sudo doesn't even work, neither under
emulation nor plain in muvm).
dbus: What we really need is the libs, so replace with that. dbus
probably won't do what we want inside the container, but for many use
cases dbus is not critical so it's okay for things to fail as long as
the libs are there.
spirv-tools-devel: Replace with spirv-tools-libs (dep)
glew-devel: Replace with libGLEW (dep)
Production builds in Fedora have a couple extra features:
* ISOs have custom overrides to set the correct volume/app IDs
* Image filenames are structured to follow roughly NVRA format
Now we support these features with extra helper scripts. If a
"image release" value is passed in, then we fully mimic the
production image build process.
This will be particularly useful for making respins of Fedora images
with updates applied.
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.
