The vagrant user used in Vagrant images needs the ability
to use sudo with no restrictions. This is fine and expected
for Vagrant images, as they are only intended to be used
for development purposes.
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).
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.
This is a variation of Cloud-Base-Generic which boots using UKIs.
This also adds uki-editbootconfig.sh script which makes the
image bootable via "UEFI firmware -> shim.efi -> UKI.efi".
Some background information:
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The initial-setup packages for firstboot were split into their own
comps group that ensures initial-setup-gui is configured to use
kwin as the Wayland compositor.
As the list of buildable variants grows, it will be harder to maintain
in the main README. Thus, split it out to its own file to keep the
README manageable.
Once the image build is done, we do not need the working tree
anymore and leaving it around causes it to get archived at the
end of CI runs when it is totally unneeded.
We now have more than one cloud system that is essentially a KVM
environment that uses cloud-init to boot, so now we declare that
"generic" and have the OpenStack and Oracle images reuse those
definitions.
Also, in preparation for layered cloud image variants, rename
them from "Cloud-" to "Cloud-Base-". Vagrant variants are
similarly prefixed to make it clear who provides them.
Finally, restructure the layout of the tmt plans to match the
description structure.
