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.
Many of the older supported AArch64 systems (particularly single
board computers) require a legacy MBR (Master Boot Record) type
partitioning to successfully boot.
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)
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.
This package is intended to be the place for Azure utilities along with
the various udev rules that currently live in the WALinuxAgent package.
At the moment it just contains the `azure-nvme-id` binary and udev rules
for providing symlinks in /dev/disk/azure/ for local, data, and
OS disks.
[root@ba1ab1388008 /]# dnf5 install dnf5-plugins --setopt=install_weak_deps=False
...
Total size of inbound packages is 2 MiB. Need to download 2 MiB.
After this operation 13 MiB will be used (install 13 MiB, remove 0 B).
...
Fixes: https://pagure.io/releng/issue/12105
Fixes: https://pagure.io/releng/issue/12106
systemd 256 added a new feature which wants to create users on
boot if none exist yet:
3ccadbce33
We don't want that, cloud-init handles this situation. So let's
disable it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The amazon-ec2-utils package includes udev rules that make it easier to
identify block storage devices and sets some configuration for other
storage devices.
Users can run awscli2 to manage their AWS cloud resources.
The ec2-instance-connect package allows one click console access to a
Fedora instance from the AWS console (website).
Signed-off-by: Major Hayden <major@redhat.com>
dnf5 (in obsoleting-dnf mode) provides /usr/bin/yum and obsoletes
yum, so we should drop the 'dnf-yum' entries (which installed
yum). dnf5 also appears to provide and obsolete microdnf, so we
should replace microdnf with dnf5 in the minimal image, I guess.
dnf5-plugins seems the logical replacement for dnf-plugins-core
(which is not removed yet, but is specific to dnf4).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It was previously being pulled in via weak dependencies of fwupd,
but we removed fwupd in #47 and now it's not there any more. It
is needed for the first boot resize by cloud-init to work, since
we use a btrfs filesystem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The F39 minimal and generic container both had util-linux-core in
them. If this wasn't an intentional change, let's add it back.
Also note that util-linux wasn't actually removed in the change linked
in https://bugzilla.redhat.com/show_bug.cgi?id=1951111#c1
Use consistent network device names for network devices instead of
forcing the old "ethX" names from pre-2017. This ensures that
specialized network devices, such as SR-IOV devices, are easy to
recognize and configure inside a Fedora instance on a public cloud or
OpenStack cloud.
FESCo ticket: https://pagure.io/fesco/issue/3190
Change proposal: https://fedoraproject.org/wiki/Changes/EnableConsistentDeviceNamingCloud
Signed-off-by: Major Hayden <major@redhat.com>
The dracut package contains tools to create bootable initramfses for the
Linux kernel. Historically, neither the Container/Dockerfile nor the
Kickstart equivalents of the fedora-toolbox OCI images contained dracut.
The KIWI description of the image was including dracut because it's
listed as a Requires(pre) of the grub2-tools package [1].
Unless someone comes forward and says that they are using Toolbx to hack
on the boot stack, it's better to retain the status quo for the sake of
a smaller image.
Since an RPM's %pre scriptlet is run before a package is installed [2],
it should be safe to remove dracut after the grub2-tools package has
been installed.
[1] https://src.fedoraproject.org/rpms/grub2
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/https://pagure.io/fedora-kiwi-descriptions/pull-request/40
They are currently being pulled in as dependencies of dracut and
grub2-tools respectively. However, since they are explicitly mentioned
in the list of default RPMs on Fedora Silverblue and Workstation [1],
they should be mentioned here too, especially since packages like dracut
and grub2-tools are related to booting the host operating system and
might not be useful in a container.
[1] https://pagure.io/fedora-comps/https://pagure.io/fedora-kiwi-descriptions/pull-request/40
Fedora Silverblue and Workstation, and so the Kickstart equivalent of
the fedora-toolbox OCI image, contain langpacks-en by default. It's
absence leads to a significant difference in the list of RPMs, which is
better to avoid so close to the Fedora 40 final release:
-abattis-cantarell-vf-fonts-0.301-12.fc40.noarch
-default-fonts-core-sans-4.0-12.fc40.noarch
-fonts-filesystem-2.0.5-14.fc40.noarch
-google-noto-fonts-common-20240301-3.fc41.noarch
-google-noto-sans-mono-vf-fonts-20240301-3.fc41.noarch
-google-noto-sans-vf-fonts-20240301-3.fc41.noarch
-google-noto-serif-vf-fonts-20240301-3.fc41.noarch
-hunspell-1.7.2-7.fc40.x86_64
-hunspell-en-0.20201207-9.fc40.noarch
-hunspell-en-GB-0.20201207-9.fc40.noarch
-hunspell-en-US-0.20201207-9.fc40.noarch
-hunspell-filesystem-1.7.2-7.fc40.x86_64
-langpacks-core-en-4.0-12.fc40.noarch
-langpacks-fonts-en-4.0-12.fc40.noarch
-liberation-fonts-common-2.1.5-9.fc40.noarch
-liberation-mono-fonts-2.1.5-9.fc40.noarch
-liberation-sans-fonts-2.1.5-9.fc40.noarch
-liberation-serif-fonts-2.1.5-9.fc40.noarch
-sil-mingzat-fonts-1.100-5.fc40.noarch
The plan is to investigate if Toolbx containers can use some of these
packages from the host. However, that needs to be co-ordinated with the
toolbox(1) binary, and has to be a done in a way that works across a
wide variety of container and host combinations.
Until then, it's safer to retain the status quo.
https://pagure.io/fedora-kiwi-descriptions/pull-request/37
It's the *Google* image that's required to have a 10 GB root
for performance reasons, not the EC2 image, as the comment says,
but the change was inadvertently applied to the EC2 image not
the Google one. This means our Google image is slow and our EC2
images are failing to be published as AMIs.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Gary Buhrmaster noticed gzip was missing from the Fedora 40 container.
An extremely quick and gross diff produced by doing:
podman run -it --rm --entrypoint /usr/bin/rpm fedora:39 -qa \
| sort | uniq | awk '{ split($0,a,"-[0-9]"); print a[1] }' > f39.txt
shows the following for Fedora Minimal 39 -> 40:
-abattis-cantarell-vf-fonts
+audit-libs
-default-fonts-core-sans
-fonts-filesystem
-google-noto-fonts-common
-google-noto-sans-mono-vf-fonts
-google-noto-sans-vf-fonts
-google-noto-serif-vf-fonts
-gpg-pubkey
+gpg-pubkey-a15b79cc
+json-c
-langpacks-core-en
-langpacks-en
-langpacks-fonts-en
+libcap-ng
+libeconf
-libsigsegv
+libtool-ltdl
+pam-libs
-systemd-libs
-util-linux-core
-zlib
+zlib-ng-compat
For Fedora 39 -> 40:
-authselect
-authselect-libs
-cracklib
-gpg-pubkey
+gpg-pubkey-a15b79cc
-gzip
-libdb
-libpwquality
-libsigsegv
+libtool-ltdl
-pam
-sudo
-systemd-libs
-util-linux-core
-zlib
+zlib-ng-compat
This adds gzip and sudo back to the non-minimal container, as well as
bzip2, xz, and zstd to round out the set of [de]compression tools.
On ppc64le, power-utils is pulled in by being default in Core group.
This in turn pulls in power-utils-core, which pulls in systemd-udev.
When kiwi goes to remove kbd-misc on ppc64le only, it fails because
systemd-udev is a protected package. On other arches since it's not
installed, it works.
So, we are going to just drop this for now and revisit solutions after
Beta is out the door.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The same change was made to the Kickstart equivalent of the
fedora-toolbox:41 OCI image recently [1].
This is meant to distinguish OCI containers and images that are designed
specifically for Toolbx from others. Toolbx containers are long-lasting
pet containers for interactive command line use, which makes them
substantially different from short-lived containers running services.
Therefore, it can be useful to be able to identify Toolbx containers and
images when generating statistics about Fedora usage.
[1] fedora-kickstarts commit 0d99c64eb2721c5b
https://pagure.io/fedora-kickstarts/c/0d99c64eb2721c5bhttps://pagure.io/fedora-kickstarts/pull-request/1015https://pagure.io/Fedora-Council/tickets/issue/449
The Container/Dockerfile and Kickstart equivalents of the fedora-toolbox
OCI images installed all locale definitions, translations, and weak
dependencies (barring exceptions) [1,2]. In fact, the Containerfile
tried very hard to restore any content that was stripped out by the
fedora base image. Hence, the KIWI descriptions should do the same.
Sometimes, like in the case of the gawk and gawk-all-langpacks RPMs,
skipping weak dependencies also strips out translations.
The Kickstart files did this by decoupling fedora-container-common.ks
from fedora-container-common.ks [3], and this is the KIWI equivalent of
the same change.
The separate 'packages' elements of types 'bootstrap' and 'image' [4]
are no longer needed and have been fused into one. This avoids the need
to specify the 'ignore' child elements separately.
This change has two workarounds that deserve mention.
First, enabling weak dependencies for the packages that used to come
from the ContainerCore profile pulls in systemd, and config.xml
specifies a keytable for all the KIWI descriptions. These two combined
makes KIWI try to set the keymap/keytable using systemd-firstboot(1),
and it fails the build with:
[ INFO ]: Setting up keytable:
[ DEBUG ]: EXEC: [chroot /path/to/image-root systemd-firstboot --help]
[ DEBUG ]: EXEC: [chroot /path/to/image-root systemd-firstboot --keymap=us]
[ DEBUG ]: EXEC: Failed with stderr: Keymap us is not installed.
, stdout: (no output on stdout)
[ ERROR ]: KiwiCommandError: chroot: stderr: Keymap us is not installed.
, stdout: (no output on stdout)
This has been worked around by making the keymaps available during the
image build through the kbd-misc RPM, which is later uninstalled.
Second, KIWI isn't passing the 'ignore' child elements to DNF [5], and
hence they currently have no effect. This has been worked around by
uninstalling the RPMs later.
Some noteworthy changes in the list of RPMs in the fedora-toolbox image
after this change:
...
+gawk-all-langpacks-5.3.0-3.fc40.x86_64
...
-glibc-2.39.9000-5.fc41.i686
-glibc-gconv-extra-2.39.9000-5.fc41.i686
-glibc-minimal-langpack-2.39.9000-5.fc41.x86_64
...
-libgcc-14.0.1-0.8.fc41.i686
...
+python-unversioned-command-3.12.2-2.fc41.noarch
They are all in line with the latest Kickstart equivalent of the image.
[1] https://src.fedoraproject.org/container/fedora-toolboxhttps://github.com/containers/toolbox/tree/main/images/fedora
[2] https://pagure.io/fedora-kickstarts/blob/main/f/fedora-container-toolbox.ks
[3] fedora-kickstarts commit 30f76d387d9e7f5c
https://pagure.io/fedora-kickstarts/c/30f76d387d9e7f5chttps://pagure.io/fedora-kickstarts/pull-request/1002
[4] https://osinside.github.io/kiwi/concept_and_workflow/packages.html
[5] https://github.com/OSInside/kiwi/issues/2499https://pagure.io/fedora-kiwi-descriptions/pull-request/21
Most of the Fedora Cloud-owned profiles are limited to a subset of
architectures, generally x86_64 and aarch64 (with the exception of
the VirtualBox Vagrant image, which is x86_64 only).
