Changes in Fedora 42 For System Administrators

In Fedora 42, the /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to /usr/bin and /usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH. The same change is also done to make /usr/local/sbin point to /bin, effectively making /usr/local/bin/foo and /usr/local/sbin/foo point to the same place.

The definition of %_sbindir has been changed to %_bindir, so packages will start using the new directory after a rebuild without any further action.

Maintainers may stop using %_sbindir, but don’t need to.

On Fedora 42, the boot-splash (plymouth) now defaults to using the EFI firmware framebuffer to show the boot-splash earlier during boot.

Since the EFI framebuffer does not provide the screen’s DPI, plymouth now guesses whether 2x hiDPI scaling should be used or not based on the screen’s resolution. So Fedora 42 may use a different scaling factor for the bootsplash then before, this only impact the bootsplash.

The old behavior of waiting for the GPU driver to load before showing the splash can be restored by running:

Alternatively, the guessed hiDPI scale-factor can be overridden by running:

Change =1 to =2 to force 2x scaling. Note if this is used the specied scale-factor will apply to all displays.

Alternatively, instead of using the kernel commandline these settings can be configured through editing /etc/plymouth/plymouthd.conf. Uncomment the [Daemon] line and then add lines with:

After editing /etc/plymouth/plymouthd.conf, the initrd must be regenerated to include the updated file by running sudo dracut -f.

The fips-mode-setup utility has been removed from Fedora. To operate a system in FIPS mode, you have one of the following options instead:

Switching a system to FIPS mode after installation is no longer recommended. For example, disk encryption with LUKS, or OpenSSH key generation will make algorithmic choices during installation or first boot that are not FIPS approved when not running installation or first boot in FIPS mode.

If you still need to switch a system to FIPS mode after installation and are aware of the risks, you can add the fips=1 argument to the kernel command line. Note that if your /boot is on a separate partition, you will also have to add the partition’s UUID to the command line for the dracut FIPS initramfs module to be able to find the kernel and its checksum file, or the boot will fail. The following command does this in one step:

To disable FIPS mode, you should reinstall the system. If you need to switch an existing system — which is not recommended — you can use grubby again to remove the fips=1 command line argument.

The built-in rpm mechanism to create system users from sysusers.d metadata distributed by packages is now used to create system users, replacing the previous use of custom rpm scriptlets in individual packages.

For more information about user creation through sysusers.d, see the upstream RPM documentation.

On Fedora Atomic Desktop systems, the root mount of the system (/) is now mounted using composefs, which makes it a truly read only filesystem, increasing the system integrity and robustness. This is the first step toward a full at runtime verification of filesystem integrity.

This change follows a similar one in Fedora 41 which enabled ComposeFS by default in the Fedora CoreOS and IoT editions.

Starting with Fedora 42, Fedora Atomic Desktop is no longer available for the PPC64LE (64-bit Power Little Endian) architecture due to a lack of interest. Those who want to use Atomic on such system must either revert to a Fedora package mode installation, or build their own images using Bootable Containers which are available for PPC64LE.

Previous Fedora IoT releases used the Zezere privisioning server for initial configuration. However, this approach caused problems for some users, notably those using IPv6. Starting with Fedora 42, Zezere has been replaced with systemd-firstboot. Users who have been unable to use Zezere will have an easier and more straight forward way to configure their system, resulting in less frustration during the critical first boot experience.

The Getting Started section of the Fedora IoT documentation has been updated to reflect this change.

Fedora CoreOS now receives updates from link:https://quay.io/fedora/fedora-coreos instead of the Fedora OSTree repository. The old OSTree repository will continue to be active until Fedora 43 release. Disk images will be updated first, so new installations of Fedora 42-based Fedora CoreOS will use OCI images from the start. Existing nodes will be migrated in the future.

This change helps align Fedora CoreOS with the ongoing Bootable Containers initiative.

Fedora distributed as bootable container ships via OCI registry. Installation is typically done by conversion into a VM image or ISO installer via osbuild (image builder), however, booting from network is a useful workflow for bare-metal fleet deployments. Required files to perform such installation were previously not available in the OCI repository that could be fetched from registry in a similar manner as the bootable container. This changes in Fedora 42.

Previously, Kickstart files were only available in the Fedora RPM repository and it could be cumbersome to find appropriate RPM repository version and extract needed files instead of fetching all the needed assets from the registry only. Fedora 42 introduces an OCI repository with the files in question for each Fedora stable version.

Kickstart files will also continue to be distributed in RPM repositories.

See the Change page on the Fedora Wiki for more information.

Fedora now provides WSL (Windows Subsystem for Linux) images. They are available for download on the Getfedora cloud page.

WSL is a Windows subsystem that allows Windows users to easily run multiple guest Linux distributions as containers inside a single virtual machine managed by a Windows host.

The Fedora base container can already be used with WSL, but it is not ideal as it intentionally excludes documentation and non-essential tools, which this cloud image provides.

For documentation on how to use these images, see Fedora Cloud docs.

In this Fedora release the ansible package has been upgraded to version 11. There are many changes and for full list of them see the link: upstream documentation.

Also, the ansible-core package has been upgraded to version 2.18. Some of the notable changes include:

For more details see the upstream documentation.

Intel Software Guard Extensions (SGX) is a piece of technology that enables creation of execution enclaves. Their memory is encrypted and thus protected from all other code running on the CPU, including System Management Mode (SMM), firmware, the kernel and user space.

This Fedora update provides the SGX host software stack, architectural enclaves and development packages. The change focuses on general software infrastructure enablement. The aim is to introduce applications and features in the future, which will have a dependency on SGX.

Fedora 42 introduces a new way to handle installing RPM packages from repositories while outdated PGP keys are present in the system. Previously, such keys had to be removed manually by running rpmkeys --delete. Starting with this release, expired keys will be detected automatically before any DNF transaction and handled appropriately using a new libDNF5 plugin which is enabled by default.

For those using interactive mode, a prompt will now appear informing them about each outdated key on the system and asking for confirmation to remove it. For non-interactive users, there will be no change to the workflow.

This update improves the way software packages are downloaded and installed on Fedora. The change provides a better experience for users as it reduces the amount of I/O resources required and offsets the CPU cost of package decompression. As a result, the OS installs and upgrades the packages faster.

Note that this behavior is not being turned on by default, and thus it is explicitly opt-in for now.

Stratis 3.8.0, which consists of stratisd 3.8.0 and stratis-cli 3.8.0 includes two significant enhancements, as well as a number of minor improvements.

Most significantly, Stratis 3.8.0, introduces a revised storage stack. The motivation for this change and overall structure of the storage stack is described [in a separate post].

Stratis 3.8.0 also introduces support for multiple bindings for encryption using the same mechanism. Previously, Stratis only allowed a single binding that used a key in the kernel keyring, now multiple bindings with different keys may be used for the same pool. Similarly, multiple bindings that make use of a Clevis encryption mechanism may be used with the same pool. The number of total bindings is limited to 15.

This change enables a number of use cases that the previous scheme did not allow. For example, a pool might be configured so that it can be unlocked with one key belonging to a storage administrator, for occasional necessary maintenance, and with a different key by the designated user of the pool.

Previously, when starting an encrypted pool, the user was required to designate an unlock method, clevis or keyring. Since this release allows multiple bindings with one unlock method, it introduces a more general method of specifying an unlock mechanism on pool start. The user may specify --unlock-method=any and all available methods may be tried. The user may also specify that the pool should be opened with one particular binding, using the --token-slot option. Or the user may choose to enter a passphrase to unlock the pool instead, either by specifying the --capture-key option or a keyfile using the --keyfile-path option. Similarly, the unbind command now requires the user to specify which binding to unbind using the --token-slot option. And the rebind method requires that the user specify a particular token slot with the --token-slot option if the pool has more than one binding with the same method.

There were also a number of internal improvements, minor bug fixes, and dependency updates.

Please consult the stratisd and stratis-cli changelogs for additional information about the release.

The zlib-ng data compression library in Fedora 42 has been updated to version 2.2, specifically 2.2.4. The updated version provides new optimizations, rewrites deflate memory allocation, and improves the buildsystems and tests.

You can find release notes for version 2.2 at the following links:

Apache Traffic Server (trafficserver) in Fedora has been upgraded to version 10.x. The /etc/trafficserver/records.config file will be automatically updated to the new records.yaml format. Additional upgrade steps may be required if removed features or APIs are in use; please review the upstream documentation.

Fedora 42 provides the bpfman package.

Bpfman is a software stack simplifying the management of eBPF programs in Kubernetes clusters or on individual hosts. It comprises a system daemon (bpfman), eBPF Custom Resource Definitions (CRDs), an agent (bpfman-agent), and an operator (bpfman-operator). Developed in Rust on the Aya library, bpfman offers improved security, visibility, multi-program support, and enhanced productivity for developers.

For Fedora, integrating bpfman would streamline eBPF program loading. It enhances security by restricting privileges to the controlled bpfman daemon, simplifies deployment in Kubernetes clusters, and offers improved visibility into running eBPF programs. This integration aligns with Fedora’s commitment to providing efficient and secure solutions, making it easier for users to leverage the benefits of eBPF in their systems.

Fedora Workstation variants use connectivity checks by default. These checks can fail for multi-homed (e.g. LAN + Wi-Fi) hosts where firewalld uses IPv6_rpfilter=strict. Therefore, starting in Fedora 42, Fedora Workstation now defaults to to IPv6_rpfilter=loose to allow connectivity checks to function as intended.

For systems upgrading to Fedora 42, the new value of IPv6_rpfilter depends on whether the user has customized /etc/firewalld/firewalld.conf. If not, then the RPM upgrade process will update the configuration to IPv6_rpfilter=loose. If yes, then the existing configuration will be retained.

Note that this change is a deviation from firewalld upstream, which continues to default to IPv6_rpfilter=strict.

Fedora 42 replaces the Cockpit Navigator plugin with Cockpit Files. Last year the Cockpit project released a new officially supported Cockpit Files plugin intended to provide a modern alternative to the existing Cockpit navigator plugin. The latest release (14) supports everything which Cockpit navigator did except the creation of symlinks which is planned to be implemented.

Replacing cockpit-navigator with cockpit-files leads to a visual change within Cockpit: the Navigator menu entry will be replaced with a new File browser menu entry under Tools.

The UI of cockpit-files is different from cockpit-navigator but offers the same functionality with the exception symlink creation. cockpit-files uses PatternFly as UI toolkit, making the user experience more consistent.

Fedora 42 enables virtualization hosts to launch confidential virtual machines using AMD’s SEV-SNP technology. Confidential virtualization prevents admins with root shell access, or a compromised host software stack, from accessing memory of any running guest. SEV-SNP is an evolution of previously provided SEV and SEV-ES technologies providing stronger protection and unlocking new features such as a secure virtual TPM.

Fedora now provides a mechanism for automatically loading binaries optimized for newer versions of the x86_64 architecture using glibc-hwcaps. Users may notice faster execution times for binaries where the package maintainer opted in to use this mechanism. For a full explanation, see the Change page on the Fedora Wiki.

PostgreSQL version 15 will be retired from Fedora 42 since there are newer versions (16 and 17). Version 16 is already the default version (announced in PostgreSQL16 change), and version 17 would be the alternative.

If you still have not upgraded to the default stream 16, you should follow the standard upgrade strategy:

The opendmarc package previously included a set of optional supporting binaries which are not required to configure the service, which caused them pull a high number (80+) additional packages as dependencies. Starting with Fedora 42, the opendmarc package only contains core utilities, and additional tools can be installed separately if needed, potentially saving space for those who don’t need them. The new separate packages are:

Previously, the git package was complex, divided into multiple sub-packages, and was providing the git binary. If you wanted to satisfy those packages that required the git binary, you experienced a long and computationally intensive installation process. With this update, the git binary is now provided through the git-core package, which should reduce the amount of packages installed as transient dependency of the main package.

Fedora Linux live environments now use the Enhanced Read-Only FileSystem (EROFS), a modern, feature-rich read-only filesystem.

The pam_ssh_agent_auth package has been removed in Fedora 42 due to being outdated and rarely used.