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).
Azure provides an optional "Accelerated Networking" feature. Enabling
this feature when creating a VM enables SR-IOV and provides the guest
with a virtual function.
Supporting this requires two changes. Firstly, the kernel-modules
package is required as it contains the Mellanox drivers required for the
VF provided to the guest. Secondly, the interface needs to be ignored by
NetworkManager or it'll try and fail to bring up the device and the VM
will be unreachable except by serial console. If this is observed, it's
likely new hardware has been deployed and additional drivers need to be
added to the NetworkManager config.
See https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
for details.
