This article will guide you to enforcing DoT (DNS over TLS) on your running system and at boot time. Support is avaliable in Fedora 42. It will also guide you to set up encrypted DNS for system installation, if you want to try it with current Fedora Rawhide (Fedora 43).

Background

Traditionally, DNS queries are transferred over unencrypted datagrams through UDP port 53. This unencrypted nature provides a potential attack vector when an attacker is able to easily capture and modify DNS requests and responses. This can be mitigated by using encrypted DNS protocols such as DNS over TLS (DoT) and DNS over HTTPS (DoH).

Fedora has built in support for DNS over TLS through systemd-resolved, which is the default DNS resolver since Fedora 33. It is also possible to configure enforced or opportunistic DoT via DNSoverTLS option in resolved.conf. However, this only enables DNS encryption for system runtime. This is not enough on Zero Trust Networks where all DNS communication has to be encrypted for system runtime as well as during boot time for network boots and during system installation.

A Red Hat working group was tasked to deliver system-wide support for encrypted DNS that would satisfy the requirements for Zero Trust Networks. The latest bits landed in Fedora 42. (At this time installation support is present only in current Rawhide, future Fedora 43). While the generic idea is similar to what systemd-resolved does – it runs a local caching DNS resolver that accepts local unencrypted queries and forwards them over an encrypted channel to the upstream DNS servers. At this time systemd-resolved remains controversial and there is not much development activity. Therefore, after discussion with systemd developers, we decided to rely on a different service – unbound. However, we do plan to implement support for systemd-resolved in the future and give users a choice.

Enable DoT during system runtime

Encrypted DNS is fully integrated within NetworkManager using its new dnsconfd DNS plugin. This plugin talks to dnsconfd service, which provides a D-Bus API to configure a local DNS resolver. Only unbound is supported at the moment, but more backends will be added in the future. Dedicating the DNS configuration to a standalone service helps NetworkManager focus solely on obtaining the settings. This leaves the peculiarities of individual DNS backends to be dealt with inside dnsconfd.

Install Required Packages

Only the dnsconfd package needs to be installed as NetworkManager is already installed in Fedora by default. This package will also pull in dependencies such as unbound.

$ sudo dnf install dnsconfd
$ sudo systemctl enable --now dnsconfd

Configure NetworkManager

The next step is to configure the NetworkManager. The following snippet sets the server to Cloudflare’s 1.1.1.1 and mode to exclusive. This means that this and only this server will be used for all connections.

$ cat /etc/NetworkManager/conf.d/global-dot.conf
[main]
dns=dnsconfd

[global-dns]
resolve-mode=exclusive

[global-dns-domain-*]
servers=dns+tls://1.1.1.1#one.one.one.one

$ sudo systemctl restart NetworkManager

Installing custom CA certificate

Some DNS servers require a custom CA certificate bundle which can be installed into the default location /etc/pki/dns/extracted/pem/tls-ca-bundle.pem. Note that the dnsconfd service requires restart as well, if this file is changed.

$ cat /etc/NetworkManager/conf.d/global-dot.conf
[main]
dns=dnsconfd

[global-dns]
resolve-mode=exclusive

[global-dns-domain-*]
servers=dns+tls://10.0.0.100#custom.dns.example

$ cat <<EOF > /etc/pki/dns/extracted/pem/tls-ca-bundle.pem
----BEGIN CERTIFICATE-----
… custom.dns.example CA certificate
-----END CERTIFICATE-----
EOF

$ sudo systemctl restart dnsconfd
$ sudo systemctl restart NetworkManager

Enable DoT during system boot time

In order to enable encrypted DNS during system boot time, it is necessary to configure the initram DNS using specific kernel arguments and install the dnsconfd-dracut package. After this the initram image must be regenerated.

Install Required Packages

# dnf install dnsconfd-dracut

Set kernel arguments

# Select DoT DNS server
KERNELARGS="rd.net.dns=dns+tls://1.1.1.1#one.one.one.one"

# Only our DoT server will be used for all connections
KERNELARGS+=" rd.net.dns-resolve-mode=exclusive"

# Use dnsconfd NetworkManager plugin
KERNELARGS+=" rd.net.dns-backend=dnsconfd"

# Update kernel arguments
grubby --args "$KERNELARGS" --update-kernel 0

Regenerate the initram image

The initram image can be regenerated with various tools (like dracut), but simply reinstalling the current kernel package is the simplest solution. It will make certain that dnsconfd and any custom CA certificates are included in the image.

# dnf reinstall kernel-core

However, note that this will regenerate initram only for the latest kernel. If an older kernel is required, it is recommended to call dracut directly and pass the desired kernel in its command line arguments.

# dracut -f --kver="$KERNEL_VERSION"

Enable DoT for system installation

It is possible to enable encrypted DNS during system installation in the current Fedora Rawhide (43). The only thing that is required is to pass additional kernel arguments to the installer. The installer will take care of everything and encrypted DNS will be configured for the system installation. The configuration will also be installed on the system so it will be automatically set up for the installed system as well as for the boot process. The arguments are the same as described in “Enable DoT during system boot time”, that is:

… rd.net.dns=dns+tls://1.1.1.1#one.one.one.one rd.net.dns-resolve-mode=exclusive rd.net.dns-backend=dnsconfd"

If required, a custom CA certificate bundle can be installed with a new %certificate kickstart directive.

%certificate --dir /etc/pki/dns/extracted/pem/ --filename tls-ca-bundle.pem
-----BEGIN CERTIFICATE-----
... custom CA certificate
-----END CERTIFICATE-----
%end

Enable DoT in FreeIPA

FreeIPA is an open source centralized Identity Management solution that provides its own integrated DNS service. As of Fedora 42, it supports encrypted DNS as well. This is either in a strict mode, where non-encrypted DNS is completely disabled or in a relaxed mode, where both encrypted and non-encrypted protocols are allowed.

For certificate management, Administrators can either provide their own TLS certificates or allow FreeIPA to issue and manage them via its Custodia subsystem. This flexibility enables seamless integration into both enterprise-managed and automated deployments.

Install Required Packages

The integration of DoT into FreeIPA focuses on new deployments and encapsulates the encrypted DNS functionality in dedicated subpackages. These packages are freeipa-client-encrypted-dns and freeipa-server-encrypted-dns. This modular approach ensures that existing installations remain unaffected unless these components are explicitly installed.

$ sudo dnf install freeipa-server-encrypted-dns freeipa-client-encrypted-dns

Fresh installation

To set up FreeIPA with DoT on Fedora, simply install, deploy, and use FreeIPA as usual, but include the relevant encrypted DNS parameters when deploying. This applies to servers, replicas, and clients alike. The new functionality integrates seamlessly into standard installation workflows for new environments.

As mentioned before, administrators can either provide their own TLS certificates or allow FreeIPA to issue and manage them via its Custodia subsystem.

Using your own certificates:

For testing purposes, you can generate certificates using openssl.

$ openssl req -newkey rsa:2048 -nodes -keyout /etc/pki/tls/certs/privkey.pem -x509 -days 36500 -out /etc/pki/tls/certs/certificate.pem -subj "/C=US/ST=NRW/L=Earth/O=CompanyName/OU=IT/CN=master.ipa.test/emailAddress=email@example.com" && chown named:named /etc/pki/tls/certs/privkey.pem /etc/pki/tls/certs/certificate.pem

Use this generated certificate, as shown below, when deploying FreeIPA server by using –dns-over-tls-cert and –dns-over-tls-key, respectively. If these options are empty, a new certificate will be requested from IPA CA.

$ sudo ipa-server-install \
         --setup-dns \
         --dns-over-tls \
         --no-dnssec-validation \
         --dot-forwarder "1.1.1.1#one.one.one.one" \
         --auto-reverse \
         --domain ipa.test \
         --realm IPA.TEST \
         --hostname master.ipa.test \
         --dns-over-tls-cert /etc/pki/tls/certs/certificate.pem \
         --dns-over-tls-key /etc/pki/tls/certs/privkey.pem \
         -p Secret123 -a Secret123 -U

Existing installations

For existing deployments, administrators must take explicit action to enable DoT. This involves upgrading and installing the required packages (freeipa-client-encrypted-dns and freeipa-server-encrypted-dns). After that the ipa-dns-install commands are issued to include the encrypted DNS options. Care should be taken to evaluate the environment and ensure compatibility before enabling the new functionality.

$ sudo ipa-dns-install --dns-over-tls --dot-forwarder "1.1.1.1#one.one.one.one"

This article provides a short overview and history of the Fedora Project.

Introduction

The Fedora Project has become known for Linux innovation. Since its inception in 2003, Fedora has been a proving ground where new ideas in Linux are tested and refined by a global community of contributors. Its creation sprang from Red Hat Linux’s transformation into Red Hat Enterprise Linux. This move required a separate open-source distribution to remain on the leading edge. Over the years, this approach has nurtured developments like Wayland, rpm-ostree, and many more spin-off editions, each having its own use case. As a result, Fedora has become a cornerstone for the broader open-source world, inspiring many other models.

Prior to Fedora Linux

The beginning of Fedora starts the same as many other systems, with the development of Unix and the GNU/Linux. Unix was conceived in the late 1960s at Bell Labs. The technicalities it offered, like emphasizing modularity and portability, proved influential to future systems. The GNU Project, which contributed a key ideological foundation, urged programs to be published under the GNU General Public License. This license gave end users the freedom to modify and redistribute given software, as long as they extended the same rights downstream. In the early 1990s, Linus Torvalds released the Linux kernel. The GNU Project’s userland software and Torvalds’s kernel gave birth to “GNU/Linux” (usually abbreviated simply to Linux). Gradually distributions such as Debian, Slackware, and Red Hat Linux emerged to package these elements conveniently.

Red Hat and the transition

Red Hat Linux rose to prominence in the mid-1990s by combining RPM (Red Hat Package Manager) with a systematic method for creating, distributing, and updating packages. Its user and corporate friendliness made it stand out among other distributions. Yet as the 2000s approached, Red Hat faced opportunities with bigger commercial and governmental institutions. These organizations were attracted by Linux’s stability and cost-effectiveness, and sought multi-year support guarantees and formalized maintenance models. Red Hat began to pivot to a subscription-based enterprise solution known, thereafter, as Red Hat Enterprise Linux (RHEL). This business strategy aligned with demands for predictable release cadences and dedicated security patches. However, it also introduced a new question: what would happen to the fast-paced development tradition that had existed under Red Hat Linux?

To answer this, Red Hat attempted to continue open development under the banner of the “Red Hat Linux Project”. But that model created a lot of confusion for customers. The result was a decisive move, in 2003, to discontinue the classic Red Hat Linux brand and unveil two new branches. These were RHEL and an openly developed community distribution. The community-based operating system took the name Fedora. This was in collaboration with Warren Togami’s Fedora Project, an external repository of add-on software for Red Hat Linux. Fedora quickly coalesced as the new “upstream” community layer. Now emerging technologies could be introduced, refined, and tested by a global volunteer network before eventually being integrated into Red Hat’s enterprise offerings.

Naming the Project

In its initial phase, Fedora was referred to as “Fedora Core” with “Core” denoting the central packages curated by Red Hat employees. A separate repository, known as Fedora Extras, captured community-maintained software. Over time however, the artificial boundary between Red Hat–maintained packages and community-contributed packages became increasingly frustrating to everyone working on the project. Red Hat engineers and volunteers alike recognized that the distribution would benefit from a single, unified development process. By the mid-2000s, community leaders pressed for the elimination of Fedora Core and Fedora Extras as separate entities. This became reality with the release of Fedora 7. In this release “Core” and “Extras” became unified ensuring that all packages would be maintained under shared infrastructure and open governance. This shift definitively set Fedora on a path toward greater inclusivity, allowing volunteers and Red Hat employees to collaborate as equals.

The Fedora Project Editions, Spins, Labs, CentOS, ….

Since Fedora Linux 21, the distribution has maintained a set of “editions”, each targeting a particular environment.

• Fedora Workstation is designed for desktops and laptops, shipping with GNOME as the default interface. With Fedora Linux 42, KDE was added as another desktop and laptop option.

• Fedora Server focuses on server environments, offering packaging for critical server applications.

• Fedora Cloud is Fedora Server optimized to run on cloud platforms like AWS, Azure, etc.
  
• Fedora CoreOS is “atomic” and uses rpm-ostree to provide an atomic means of upgrading the operating system.
  
• Fedora IoT addresses Internet of Things deployments. It ensures that Fedora’s security and update mechanisms can be extended to small-scale or embedded hardware.

Over time, the distributions have been joined by specialized “Labs”. These are curated sets of packages aimed at gaming, design, robotics, and scientific computing.

Concurrent with these developments, Red Hat began rethinking the role of CentOS. This distribution had historically been a rebuild of RHEL’s source packages. Instead of simply mirroring RHEL, Red Hat inaugurated “CentOS Stream” as a midpoint between Fedora and RHEL. Under this arrangement, Fedora remains the upstream integration point, incorporating the newest features, libraries, and subsystems, under a community governance model. In CentOS Stream, Red Hat engineers refine the result into a near-final pipeline for the next RHEL release. Thus, in effect, Fedora not only drives RHEL but also aids in CentOS Stream’s progression. This intricate relationship shows Fedora’s status as a proving ground of enterprise-ready Linux technology, albeit governed by a global collective of paid and volunteer contributors.

Future goals of the Fedora Project

The Fedora Project sees continued expansion in contributor counts and new technical vistas. The project aims to remain at the forefront of container orchestration, edge computing, Internet of Things deployments, and imaginative spins such as Sway Atomic or Budgie Atomic, which repackage the immutable model for other user interfaces.

One can regard Fedora’s twenty-year saga as a success in technological progress and community organization. Tracing its lineage through Unix, GNU, Linux, Red Hat Linux, and into RHEL, Fedora endures its legacy of shared knowledge. By preserving its guiding principles of transparency, inclusive governance, and rapid iteration, with its dedication to open source, Fedora remains poised to continue as a locus of innovation, shaping the paths of CentOS Stream, Red Hat Enterprise Linux, and many other distributions. In so doing, it carries forward the spirit of Unix and GNU, that advanced operating systems share their combined efforts, all striving toward accessible and empowering computing for everyone.

The Fedora RISC-V SIG is excited to share that our RISC-V images for Fedora Linux 42 have landed on-time and without delay! If you’ve been watching our progress over the past few releases, you know that staying on schedule is a big deal, especially given our goals of eventually gaining “primary” status for RISC-V as an available Fedora Linux architecture. Previous RISC-V builds of Fedora Linux were released with a small delay compared to the other architectures, but with Fedora Linux 42, we’re right on track.

Today, we’re announcing the general availability of pre-built Fedora Linux 42 images for all our supported boards, QEMU, and container images. You can read more about these images in our previous post and under the Hardware section of the RISC-V team’s wiki. These non-official images are brought to you by the Fedora RISC-V Community.

Big Improvements, Smaller Numbers

Behind the scenes, the data tells an even more exciting story.

One way to measure and compare our efforts over time is by analyzing the number of “unresolved dependencies” in the build root. When a package is built, it typically has access to a repository containing every package built for that Fedora release–we call this the build root. Running the dnf repoclosure procedure against this buildroot by itself allows us to quantify the number of dependencies that are being fulfilled for a given build using a package built for a previous Fedora release.

• In Fedora Linux 40, the RISC-V buildroot had over 6,900 unresolved dependencies.

• Fedora Linux 41 slashed that nearly in half to around 3,800.

• Now, with Fedora Linux 42, we’re down to just 357 unresolved dependencies across 126 packages.

In other words, there are now only 357 subpackages from 126 packages in the RISC-V Koji which were not built directly for Fedora Linux 42 — a nearly 95% decrease in just one year.

That’s not just progress — it’s momentum.

These numbers represent the steady roll toward a complete and clean buildroot for RISC-V in Fedora. Every fix, every patch, and every accepted change brings us closer.

Upstream, Together

Our upstreaming work continues apace, and we want to acknowledge that none of this progress would be possible without the incredible collaboration from maintainers across the Fedora Project and beyond. Thank you to everyone who reviewed, accepted, merged, and built our patches. Your support makes this architecture possible.

We’re also excited about just how many packages build cleanly without special treatment or overlay repositories that need to be cared for. RISC-V is becoming just another architecture, and that’s exactly how it should be.

Get Involved

If you’ve got RISC-V hardware (or want to try it out via QEMU), there’s never been a better time to jump aboard the RISC-V train. Install the image, test your favorite packages, file bugs, and drop by the RISC-V Matrix channel to help us keep this locomotive rolling down the tracks.

Check out the RISC-V wiki page for more information, and we hope to see you on Matrix and helping us shape the future of Fedora Linux on open hardware.

Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 42 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.

Update your existing system

Prior to actually doing the rebase to Fedora Linux 42, you should apply any pending updates. Enter the following in the terminal:

$ rpm-ostree update

or install updates through GNOME Software and reboot.

Note

rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.

Rebasing using GNOME Software

GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.

First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.

Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update is completed. After the restart you will end up in a new and shiny release of Fedora Linux 42. Easy, isn’t it?

Rebasing using terminal

If you prefer to do everything in a terminal, then this part of the guide is for you.

Rebasing to Fedora Linux 42 using the terminal is easy. First, check if the 42 branch is available:

$ ostree remote refs fedora

You should see the following in the output:

fedora:fedora/42/x86_64/silverblue

If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use the following command:

# 2 is entry position in rpm-ostree status 
$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora Linux 42 branch.

$ rpm-ostree rebase fedora:fedora/42/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Linux 42.

How to roll back

If anything bad happens (for instance, if you can’t boot to Fedora Linux 42 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 42 and your system will start in that previous version rather than Fedora Linux 42. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 42 and roll back. So why not do it today?

Known Issues

• systemd-remount-fs.service fails to start (root mount options from /etc/fstab are not taken into account anymore with composefs): https://gitlab.com/fedora/ostree/sig/-/issues/72

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during rebase of Fedora? For example from Fedora 39 Silverblue to Fedora 42 Silverblue?

Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (39->40->41->42 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

$ rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this blog post.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/42/x86_64/kinoite

The newly released Fedora KDE Plasma Desktop 42 introduces out-of-box support for running x86 and x86-64 programs on ARM systems. This is accomplished by leveraging the emulation stack originally developed for Fedora Asahi Remix. This work is now integrated into Fedora Linux proper. This makes it available for all ARM systems running Fedora Linux, not just Apple Silicon Macs.

How Is This Accomplished

To make it possible to run x86 programs via emulation, we leverage several tools, each solving a specific problem:

• FEX, a fast emulator that can run x86 and x86-64 programs on ARM Linux hosts
• muvm, a tool that can run another program inside a microVM
• binfmt-dispatcher, a simple dispatcher that can dynamically pick the best emulator to use when an x86 or x86-64 program is started

With this setup, when a non-native program is run, the kernel invokes binfmt-dispatcher via the binfmt_misc interface. The dispatcher picks the best emulator to use. This is based on the program, the system it’s running on, and its own configuration. By default, we use the FEX emulator, which provides the best compromise between performance and compatibility for most programs. FEX only support host systems running a 4k page-size kernel. Thus, when running on a system with different page-size (such as Apple Silicon Macs running Fedora Asahi Remix 42, which use a 16k page-size), the dispatcher will automatically run FEX inside muvm. This will spin up a microVM with a 4k page-size kernel for compatibility.

If the user prefers to use a different emulator (such as box64 or QEMU), that can be configured globally, or on a per-program basis. The dispatcher automatically installs any missing dependencies via DNF whenever a non-native program is run for the first time that requires them. This installation requires confirmation by the user.

Library Availablity

FEX relies on an immutable filesystem containing a large set of commonly used x86-64 and x86 libraries. However, it cannot contain every library, so it is possible that a program could fail to start due to missing dependencies. Should that happen, consider submitting a pull request to the Kiwi description to get it added. It is also possible to overlay locally additional dependencies, though you should consider this as experimental at this stage. In general, this feature will work best with programs that have reduced or minimal dependencies. This is common with a lot of commercial software. While it is possible to run complex FLOSS applications with a wide dependency web, we recommend just using the native ARM version whenever that’s an option. That will always provide the best performance.

Feature Availability

This new feature is available out of the box on Fedora KDE Plasma Desktop 42. It is also available on Fedora Asahi Remix, in both the KDE Plasma and the GNOME editions. Additionally, Fedora Asahi Remix includes a gaming emulation stack based on Steam, and has dedicated documentation for this feature. On other Fedora editions, you can run $ sudo dnf install @x86-emulation to make this feature available.

It’s also worth noting that while we have specifically targeting x86 emulation on ARM hosts, the same approach could be used for other hosts and targets in the future.

Fedora 42 has been released! So let’s see what arrives with the new releases for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic and Budgie Atomic).

New COSMIC Atomic variant

The new COSMIC desktop has been packaged for Fedora and a new Atomic variant created for it thanks to Ryan Brue. It is not yet available on the website but should be soon. See fedora-websites#351.

See the Fedora change request.

Changes for all variants

composefs enabled by default

Following Fedora CoreOS in Fedora 41, Fedora Atomic Desktops are now using composefs by default. This is an important first step towards better integrity for the system content.

Note: As a side effect of this change, the systemd-remount-fs.service unit may fail to start on your system. Until we find a good way to fix this, a workaround is available in the atomic-desktops-sig#72 issue or in the common issue thread on the forum.

See the Fedora change request and the tracking issue atomic-desktops-sig#35.

Migration to a static GRUB config

As part of the move to composefs, we had to migrate systems to use a static GRUB config.

This also removes the duplicate entries in the boot menu for installations that pre-dates Fedora 41.

The transition will happen automatically during the first boot on Fedora 42. You can verify that it worked by looking at the status of the bootloader-update service:

$ sudo systemctl status bootloader-update.service

We are still missing documentation on how to change some GRUB settings now that the configuration is static. See the tracking issue atomic-desktops-sig#73.

Custom keyboard layout set on installation (for LUKS unlock)

This fix is important for setups where the root disk is encrypted with LUKS and the user is asked for a passphrase on boot. The keyboard layout is now set by Anaconda as a kernel argument during installation. If you want to later change the keyboard layout used for the LUKS password prompt, you will have to update the kernel argument.

Example to set the keyboard layout to the french keyboard:

$ sudo rpm-ostree kargs --append=vconsole.keymap=fr

Example to replace an existing layout by another:

$ sudo rpm-ostree kargs --replace=vconsole.keymap=de

See atomic-desktops-sig#6.

No longer building for PPC64LE

According to the countme statistics, we did not have users on PPC64LE so we decided to stop building the Fedora Atomic Desktops for that architecture.

If you relied on those images, you can migrate to Fedora Bootc images (which are available for PPC64LE) or use a conventional Fedora package based installation.

See the Fedora change request.

What’s new in Silverblue

GNOME 48

Fedora Silverblue comes with the latest GNOME 48 release.

For more details about the changes that alongside GNOME 48, see What’s new in Fedora Workstation 42 on the Fedora Magazine and Looking ahead at 2025 and Fedora Workstation and jobs on offer! from Christian F.K. Schaller.

What’s new in Kinoite

KDE Plasma 6.3

Fedora Kinoite ships with Plasma 6.3, Frameworks 6.11 and Gear 24.12. See also
What’s New in Fedora KDE 42? on the Fedora Magazine.

What’s new in Sway Atomic

Nothing specific this release.

What’s new in Budgie Atomic

The default software center for Budgie Atomic is now Plasma Discover. To rebase from Fedora 41 to 42, you will have to use the command line as rebasing via GNOME Software will move your system to Fedora Silverblue.

See: fedora-budgie/project/issue/5.

Changes in unofficial images

Until we complete the work needed in the Fedora infrastructure to build and push official container images for the Atomic Desktops (see releng#12142 and cloud-image-uploader#37), I am providing unofficial builds of those. They are built on GitLab.com CI runners, using the official Fedora packages and the same sources as the official images.

You can find the configuration and list on gitlab.com/fedora/ostree/ci-test and the container images at quay.io/organization/fedora-ostree-desktops.

Container images signed with cosign (sigstore)

The unofficial container images are now signed with cosign. You can configure your system to verify the signature of the images using the instructions from the project README.

Container images available for aarch64

We are now building all our variants for the aarch64 architecture as well.

Goodbye to Sericea and Onyx (now Sway Atomic & Budgie Atomic)

We have now removed all container images under these names. Use the new names:

• Sericea: sway-atomic
• Onyx: budgie-atomic

Unofficial, experimental Fedora Asahi Remix Atomic Desktops

We are now producing unofficial, experimental bootable container images targeting Apple Silicon, using the packages from the Fedora Asahi Remix project.

The images are in a working state, but the installation procedure is not ready for general use. We thus only recommend that you give this a try if you are ready to help with the development or are ready to re-install you system and lose data.

See: fedora-asahi-remix-atomic-desktops project on GitHub

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 42. Look for upcoming announcements in their Discourse.

I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA proprietary drivers, extra media codec, out of tree kernel drivers, etc.).

What’s next

Roadmap to Bootable Containers

The next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.

We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.

Turning the sysext experiment into a good experience

Systemd system extensions (sysexts) are a new option when you need some applications available on your system and can not run them in containers or as Flatpaks for various reasons. They offer an alternative approach to package layering as they do not increase update time and can be enabled or disabled as needed.

Support for sysexts is still in development for the Atomic Desktops but they already provide advantages over package layering for some use cases. See the currently experimental project: github.com/travier/fedora-sysexts.

Unifying the Atomic Desktops documentation

We would like to unify the documentation for the Fedora Atomic Desktops into a single one instead of having per desktop environment docs which are mostly duplicate of one another and need to be constantly synced.

See the tracking issue atomic-desktops-sig#10 if you want to help us do that.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

• Atomic Desktops SIG: Issue tracker (gitlab.com/fedora/ostree/sig), #atomic-desktops:fedoraproject.org
• Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
• Kinoite: KDE SIG, #kinoite:fedoraproject.org
• Sway Atomic: Sway SIG, #sway:fedoraproject.org
• Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org
• COSMIC Atomic: COSMIC SIG, #cosmic:fedoraproject.org

We are happy to announce the general availability of Fedora Asahi Remix 42. This release brings the newly released Fedora Linux 42 to Apple Silicon Macs, following our Beta release last month.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all the exciting improvements brought by Fedora Linux 42. Notably, the new FEX integration provides an easier way to run x86 and x86-64 binaries out of the box via emulation. It also continues to provide extensive device support, including the recently added microphone support for MacBook laptops.

Fedora Asahi Remix offers KDE Plasma 6.3 as our flagship desktop experience, with all of the new and exciting features brought by Fedora KDE Plasma Desktop 42. It also features a custom Calamares-based initial setup wizard. A GNOME variant is also available, featuring GNOME 48, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.

You can install Fedora Asahi Remix today by following our installation guide. Existing systems, running Fedora Asahi Remix 40 or 41, can be updated following the usual Fedora upgrade process. Upgrades via Fedora Workstation’s Software application are unfortunately not supported and DNF’s System Upgrade plugin has to be used.

Please report any Remix-specific issues in our tracker, or reach out in our Discourse forum or our Matrix room for user support.

Fedora Linux provides a wide variety of users with leading edge open source technology in a community developed and maintained operating system. Fedora KDE releases combine the reliable and trusted Fedora Linux base with the KDE Plasma desktop environment. It provides a selection of KDE applications – simple by default, yet powerful when needed.

New with this release cycle, the KDE Plasma Desktop is now a full-fledged Edition. It is maintained by the KDE Special Interest Group through the Personal Systems Working Group. As an Edition, it is now one of the flagship experiences for Fedora Linux. This recognizes the mutual successes and commitments of the Fedora and KDE communities.

The Fedora KDE Plasma Desktop Edition is well-suited for many needs, including those of creators, scientists, developers and gamers. Check out the brand new website to learn more!

KDE Plasma 6.3

KDE developers continue to release new features, fix bugs and fine-tune the desktop experience to improve on the now well-established foundation of Plasma 6. Fedora KDE 42 ships with Plasma 6.3.4 featuring:

• Robust drawing tablet configuration, including better screen area mapping, calibration, pressure curve and range setting, and button mapping
• Display improvements. This includes overhauled fractional scaling that produces sharper images even at high zoom levels. More accurate color management is provided – even with Night Light enabled
• Easier monitoring of your device, including accuracy and efficiency improvements to System Monitor, greater GPU and battery detail in Info Center, and direct access to individual print queues from the widget

Fedora KDE across devices

Power (ppc64le) systems

Fedora KDE now supports Power Systems (ppc64le architecture). Thanks to Dan Horák, we now have the full KDE stack – including PIM tools like KMail and Kontact – available on Power. Installable live images are also available for OpenPOWER-based systems, like the Talos Workstation from Raptor Systems.

Note that Fedora KDE for ppc64le is available on a best-effort basis, and is not “release-blocking”. This means Fedora Linux releases will not be stopped by bugs impacting that architecture). Community assistance to support this new platform is welcome!

x86_64 emulation on ARM-based devices (AArch64)

Fedora KDE now has significantly expanded usability on ARM-based (AArch64) devices. This is the result of contributors Alyssa Rosenzweig, Davide Cavalca, and Neal Gompa integrating support for x86 emulation powered by FEX. This allows x86_64 applications to work on ARM using a Fedora FEX rootfs image, and is particularly optimized for running Windows or Steam applications.

Read more about this new feature here: New in Fedora: Running x86 programs on ARM systems

Fedora Linux 42 general updates

Some of the key updates occurring in the core components of Fedora Linux 42, which directly impact the KDE Plasma Desktop Edition, include:

• Fedora default wallpapers are now delivered in the JXL format instead of PNG, reducing file sizes while maintaining quality
• More laptop cameras used in recent models will work out-of-the-box, following up on work done in Fedora Linux 41
• System boot times should be faster, as the plymouth system component will no longer load the full graphics driver before showing the system splash screen
• With the Anaconda installer running as a native Wayland application, language selections now sync between the live environment and installed system
• Executable file placement is simpler, as anything previously in /usr/sbin is now merged into /usr/bin

Wrap-up

The Fedora Project and the KDE Community hope that you’ll find the Fedora KDE Plasma Desktop 42 to be a trustworthy, powerful and easy-to-use desktop operating system. When you’re ready to check it out, click here for download links and verification instructions.

If you use and enjoy Fedora KDE, consider contributing in the Fedora Project, the KDE Community, the Fedora KDE Special Interest Group, or all of the above!

Fedora Linux 42 is the answer to life, the universe and everything! It’s also the latest release of one of the leading providers of free, open source software, The Fedora Project. We’ve selected a few notable changes in the newest version of Fedora Workstation 42 that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.

GNOME 48

In Fedora Workstation 42, you can enjoy the latest features the GNOME software release has to offer, plus benefit from an array of system enhancements! These are only a few of the many great features in GNOME 48, so do check out their release notes to read about all of the goodness in this release.

Well-Being Feature

A great new addition in this latest release is GNOME’s well being feature. This includes a screen time tracking function, break reminders, and the ability to set your movement break schedule times. Thank you to the good folks at Endless for supporting the GNOME foundation with a grant that has helped them work on this new feature.

Wayland Accessibility Improvements

Orca screen reader capabilities are now available on Wayland. The Orca shortcuts now function correctly. This is another great step towards having assistive technologies as part of the default for the GNOME display manager.

Triple Buffering for Enhanced Performance

GNOME 48 introduces a dynamic triple buffering feature in this latest release, and Fedora Workstation users can enjoy this too! This change is the culmination of over five years of reviews and testing, giving users more fluid animations and fewer skipped screens. Well done everyone! This was a testament to patience and commitment to a great user experience.

Notifications Stacking

In Fedora Workstation 42, there is a neat new feature that allows notifications to be stacked in a list. Notifications from the same app are grouped together. These improvements will stop your notification list from growing too large and gives a much better user experience overall.

Additional Fedora Linux 42 Features to Enjoy!

IBus Speech-to-Text

In Fedora Linux 42, ibus-speech-to-text provides a new input method that enables voice dictation in any application supporting IBus. It offers offline voice recognition, preserving user privacy, supports multiple languages through downloadable models, and integrates seamlessly with existing IBus infrastructure.

Fedora WSL

Recent versions of Windows support running Linux guests via Windows Subsystem for Linux (WSL). These can be distributed via tarballs, Appx packages, or via the Windows Store. Starting with this Fedora Linux 42 release, we now produce Fedora Linux images for WSL users. A dedicated image with documentation allows people to easily try out a Fedora Linux environment on their Windows installations, so when it comes time to install a Linux distribution on their computer, they can be more confident when choosing Fedora Linux.

DNF5

There has also been some work done with DNF5 which now includes new logic that will remove expired and obsolete repository keys from the system. This means users can enjoy the automatic management of repository keys during software installation or upgrades.

Anaconda Web UI Installer

By no means lastly, we have a brand new installer option for Fedora Workstation 42 — Anaconda’s Web UI installer. With this new feature, the biggest benefit to Fedora Linux users is the new guided partitioning function. This provides more powerful automatic partitioning, where the user will select a goal and have additional customization possible. This change also comes with a new “Reinstall Fedora” which allows users to easily reinstall their system if something goes wrong. Another new feature is improved support for dual-boot configurations. This new web-based UI is the default for the OS installer only on the Fedora Workstation edition right now.

While this is the end of this short snapshot of some of the newness in Fedora Linux 42, don’t panic! You can check out our Fedora Linux 42 Change Set page for even more details about all the features and changes that went into Fedora Linux 42. We hope you enjoy this latest release of Fedora Linux. So long, and thanks for all the fish!

Seventy-five thousand generations ago, our ancestors set a vast computer in motion, asking it to produce the ultimate Linux distribution…

No, wait. It wasn’t quite that long ago. That was a different thing. But in both, the answer to life, the universe, and everything turns out to be: forty-two. In our case, Fedora Linux 42, which is now officially released.

Every Fedora Linux release is a gigantic community effort — it does almost seem infinitely improbable that all of this software made by a whole planet of open source developers could come together so nicely. Yet, here we are again! Thank you so much to everyone who works so hard on Fedora and in all of our upstream projects.

Upgrade in place

If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it’s not very different from just rebooting for regular updates, except you’ll have a little more time to get a hot beverage from the machine. Perhaps something almost, but not quite, entirely unlike tea.

Or, start fresh

If this is your first time in space running Fedora Linux, or if you just want to start fresh on an uninhabited system, download the install media for our flagship Editions (Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, IoT),  for one of our Atomic Desktops (including Silverblue and Kinoite), or for alternate desktop options (like Cinnamon, Xfce, or the new and appropriately-thematic Cosmic Desktop spin).

What’s new?

We’ve promoted our KDE Plasma Desktop offering to “Edition” status. The Fedora KDE team has been hard at work making sure bugs get fixed and everything is polished just so. We’re confident that this can stand along our other amazing flagship offerings.

I know the naming is a bit confusing, with GNOME-powered “Workstation” using a generic label while KDE Plasma Desktop has the tech right in the name. We’ll get that figured out eventually. If you don’t know where to start, don’t panic. Pick one and see how it goes. They’re both excellent desktop environments with great upstream communities, and the same Fedora system underneath it all.

We also have a new alternative desktop choice: COSMIC. This is a modern, written-all-in-Rust desktop environment from our friends over at System76.

Perhaps most excitingly, we have a new installation interface! The previous UI was designed to manage a lot of before-you-even-start configuration choices. Over the past decade, though, we’ve gone to “get the full system installed with no fuss, then set up what you need from a complete environment”. That made the “hub and spoke” model more confusing than helpful. The new UI is streamlined and sleek, just like the Heart of Gold.

Of course, there are other big changes, as well as the usual updates to thousands of packages. See the Fedora Linux 42 Release Notes for all of the details, and don’t miss the “What’s New?” posts here on Fedora Magazine.

Last minute warning!

No, it’s not the Vogons, but it is ugly. We discovered a problem with the Live boot media at the last minute, and since the release was already out of the airlock, we can’t do much about it. It doesn’t damage anything, but is annoying: just booting the Live media adds an unexpected entry to the UEFI boot loader even when Fedora Linux 42 is not installed to the local system.

This is primarily a concern when you are dual-booting with a different operating system, or if you’re just running the Live image and not intending to actually install.

The problem is mostly harmless cosmetic, but still, we should have caught it sooner. Apparently this was posted in our local planning office, but we didn’t go down to the basement past the “Beware of the Leopard” sign to find it.

You can read more about this in the Common Bugs entry for this issue, including how to remove the unwanted entry (and how to avoid the problem altogether).

What else could go wrong?

We hope nothing will, but if you run into a problem, visit our Ask Fedora user support forum. This includes a category where we collect common issues and solutions or work-arounds.

A last note

As you may already know, this is my last release as Fedora Project Leader. We’re welcoming Jef Spaleta into the role, with a handover at Flock to Fedora in June. It’s tempting to sign off with “so long, and thanks for all the fish” — but I’m not planning on going far. I’ll be around Fedora stuff until the (restaurant at the) end of the universe.

A good hitchhiker always knows where their towel is. If you’ve lost track of yours, don’t worry. We’ve got you covered. In collaboration with the Fedora Design Team, our friends at Hello Tux are offering what I think you’ll agree is the most hoopy distro swag ever made. We’ll be handing them out at Flock in Prague. I hope to see you there, but if you can’t make it, you can order one at a discount with the code FEDORA5.

Comments, congratulations, and so forth

Let’s talk over at Fedora Discussion. See you there!

Wireplumber is the session and policy manager for Pipewire. It has its own systemd user service. It is a separate project, with separate concerns. Current version is 0.5.8 on Fedora Workstation 41.

Session managers save the current state of open audio applications along with their connections, allowing sessions to be easily restored without having to manually open each application, load individual settings files, and reconnect all connections – LinuxAudio

As you have seen in the previous article, we can add nodes via Pipewire configuration files or arbitrary CLI commands. But the operating system is a complex dynamic system. A lot of things can happen; for example, you can plug in your headphones any time, or you can switch between video and audio streaming. There appears to be a need for a separate controller to react to the various multimedia events. This controller or manager is Wireplumber.

What is included with Wireplumber

Let’s look at the installed files before moving to documentation. There are some utilities, like wpctl and wpexec, a few configuration files, and quite a lot of Lua files in the scripts folder.

rg@f41:~$ rpm -ql wireplumber
/usr/bin/wireplumber
/usr/bin/wpctl
/usr/bin/wpexec
/usr/share/wireplumber/wireplumber.conf
/usr/lib/systemd/user/wireplumber.service
/usr/share/wireplumber/scripts/client/access-default.lua
...

Wireplumber comes with shared libraries. Take a moment to review the module names.

rg@f41:~$ ls -l /usr/lib64/wireplumber-0.5/
-rwxr-xr-x. root libwireplumber-module-dbus-connection.so
-rwxr-xr-x. root libwireplumber-module-logind.so
-rwxr-xr-x. root libwireplumber-module-standard-event-source.so
...

As an example, the logind module, shown in this list, is used to check some logic involving bluetooth and logind active seat.

Utility Programs

Two utilities are available in the wireplumber package.

• Wpexec contains the execution context; you will see it in use in some Lua executable files.

• Wpctl allows the dynamic modification of settings. To check all available settings, use wpctl settings.

rg@f41:~$ wpctl
Usage:
  wpctl [OPTION…] COMMAND [COMMAND_OPTIONS] - WirePlumber Control CLI

Commands:
  status 
  get-volume ID
  inspect ID
  set-default ID
  set-volume ID VOL[%][-/+]
  set-mute ID 1|0|toggle
  set-profile ID INDEX
  set-route ID INDEX
  clear-default [ID]
  settings [KEY] [VAL]
  set-log-level [ID] LEVEL

Configuring

The configuration file is similar, to some degree, to the Pipewire configuration file:

rg@f41:~$ less /usr/share/wireplumber/wireplumber.conf
context.spa-libs = { ... }
context.modules = [ ... ]
wireplumber.profiles = { ... }
wireplumber.components = [ ... ]
wireplumber.components.rules = [ ... ]
wireplumber.settings.schema = { ... }

Sections spa-libs and modules import a few audio and Pipewire libraries. The profiles section defines a few basic profiles in terms of the offered features (audio/video/bluez). The components section loads a list of various functional parts from the modules. These can range from logging to Lua scripting engine and event hooks. Each component provides a specific feature. The settings section contains well-known multimedia settings with a detailed description. Configuration can be changed using wpctl or homedir drop-in configuration files.

Example

In the following example, we disable a specific feature of the main profile. Don’t forget to revert the change once tested.

cat <<EOF > ~/.config/wireplumber/wireplumber.conf.d/50.conf
wireplumber.profiles = {
  main = {
    hardware.video-capture = disabled
  } }
EOF

rg@f41:~$ systemctl --user restart wireplumber.service

Interaction with Pipewire

Wireplumber interacts with Pipewire via metadata objects. Let’s use wpctl settings to change one of the well-known settings, like the default sink volume.

rg@f41:~$ wpctl settings device.routes.default-sink-volume 0.23
rg@f41:~$ pw-metadata -n sm-settings 0 device.routes.default-sink-volume
Found "sm-settings" metadata 36
update: id:0 key:'device.routes.default-sink-volume' value:'0.23' type:'Spa:String:JSON'
...

Notice that using pw-metadata shows Pipewire has the updated value for this setting. To make the setting persistent across restarts, we can save it in the Wireplumber persistent state.

rg@f41:~$ wpctl settings --save device.routes.default-sink-volume 0.23
rg@f41:~$ cat ~/.local/state/wireplumber/* 
device.routes.default-sink-volume=0.23
...

It is worth your time to investigate all the other saved properties. You will find the current sink volume. You will also find some client or application-specific settings. The same is true for interaction with gnome-sound-panel. When you change the GUI volume, you should see the updated value saved in the state folder. When you change the default sink from speaker to headset, you should see this reflected in the wpctl status output.

It would also be beneficial to look over the Lua scripts to understand the logic behind their actions and perhaps to find templates that you can use as examples for your own configurations.

Lua Scripting

It is worth mentioning a little bit about the scripts. Lua is a simple and easy-to-learn scripting language. The scripts, in many cases, are importing some shared objects (i.e. spa-plugins) that provide the ability to orchestrate the Pipewire graph. In this way, a more complex logic is achievable. Check media-role-nodes.conf for an example of such logic. There media streams are grouped by roles and assigned to virtual sinks with different priorities for gaming, multimedia, voice assistant, navigation, emergency alarms, etc.

In the previous article, whenever we chose the --target argument for pw-play, the logic of creating the necessary node links was implemented by Wireplumber in the find-defined-target.lua file provided by this package.

Example

Here we demonstrate creating a simple script to list all streaming nodes.

cat <<EOF > ~/.local/share/wireplumber/scripts/10-medialog.lua
log = Log.open_topic("logger-media")

node_om = ObjectManager {
  Interest {
    type = "node",
    Constraint { "media.class", 
                 "matches", 
                 "Stream/Output/Audio", type = "pw-global" 
               }
  }
}

node_om:connect("object-added", function (om, node)
  log:notice(node, "Process [" .. node.properties["application.process.binary"] ..
  "] -- [" .. node.properties["media.name"] .. "]"
)
end)

node_om:activate()
EOF

We can include this as a separate Wireplumber feature and then restart the wireplumber.service and verify using journalctl :

cat <<EOF > ~/.config/wireplumber/wireplumber.conf.d/70-media.conf
wireplumber.components = [
  {
    name = "10-medialog.lua", type = script/lua
    provides = logger-media
  }
]

wireplumber.profiles = {
  main = {
    logger-media = required
  }
}
EOF


rg@f41:~$ systemctl --user restart wireplumber.service
rg@f41:~$ journalctl --user -u wireplumber.service -g logger-media

12:38:00 logger-media: <WpNode:99:0x564> 
Process [gnome-shell] -- [bell-window-system]
12:38:00 logger-media: <WpNode:87:0x564> 
Process [firefox] -- [The Woods in Lorn]

Alternatively, you can execute the lua scripts individually by including the shebang #!/usr/bin/wpexec as the first line.

Conclusions

In this article we investigated the capabilities offered by a powerful media session manager and demonstrated implementing our own session logic. Wireplumber docs are well written and describe this topic, and much more, in greater detail. Thanks to the people and organizations maintaining all the above-mentioned packages.

On March 28, 2025, we brought Fedora to Murang’a University of Technology in Kenya. The event introduced students to open source, Fedora Linux, and the many ways they can participate in the global Fedora community.

This wasn’t just another tech talk. It was an open conversation about freedom, community, and innovation—core pillars of both Fedora and the open source movement.

Why open source matters in Kenya

In Kenya, and much of Africa, many students still lack exposure to open source tools, communities, and practices. Technology education often focuses on proprietary systems, and access to learning materials is limited. Curriculum often takes time to be updated, and you could be left behind. For example, most computers in our lab are outdated as many still run on dual-core processors with 4GB RAM, and most use unsupported versions of Windows. Internet speeds can be unreliable as well, which makes software updates a challenge or not possible at all. Replacements take a long time, and students often work in shifts due to limited equipment. Yet, there is a hunger to explore, create, and connect with the global tech ecosystem.

Proprietary software has limited student’s creativity and opportunity. Licensing costs prevent many from using or experimenting with the tools they need. Open source gives students freedom—freedom of choice and freedom from financial burden, to learn, build, and even start their own projects.

Events like ours help bridge that gap. We made open source a real option for students—not just something they hear about online.  We showed them options to consider, places to obtain it, and how to get started using it.

Outreachy and the spark

The  Open Source at Murang’a event was inspired by my journey as an Outreachy applicant. I discovered Outreachy a while back while looking for opportunities to grow in tech without needing industry experience or big connections. At that time, I was still a student, and my skills were primarily practiced through personal projects I built on my own. I applied for Outreachy based on my essays alone and got selected for this contribution phase. 

“I wanted others to see that open source is not something far away. It’s something they can be part of today.” – Joseph – Avalanche Ambassador

Opening the door to Open Source

We began by exploring the fundamentals of open source—the four freedoms, licensing models, and collaborative development. Most attendees were new to these ideas. The concept that software can be free, available, community-driven, and globally impactful sparked them.

From there, we looked at Fedora’s history, its community-driven governance, and its diverse editions built for different user needs. Students were curious about Fedora’s place in the Linux ecosystem and impressed by its role in shaping modern computing.

“Learning about Fedora made me realize there’s a global community I can be part of—right from Murang’a.”  – John Mwangi

How can you contribute?

Most students believed that contributing to open projects required advanced programming skills but we broke that myth. I introduced them to Fedora’s various contribution pathways—writing documentation, translating content, testing features, designing UI, and community building.

One moment stood out: when students realized their storytelling, writing, or design skills could directly contribute to a global project. That shift in mindset was powerful.

“I thought open source was just for tech experts. Now I know I can contribute through writing. I feel seen.” – Prudence, MUT student

Breaking barriers in Kenya

When we look at tech education in Kenya, we still face major hurdles—limited resources, infrastructure challenges, and lack of awareness about global communities like Fedora. But this event showed that curiosity and collaboration can beat those odds.

We had over 70 students attend, mostly from the university’s Computer Science and IT departments A few came from other departments, and 3-5 from local groups as well. It took a lot of work to get the word out—working with local partners and sharing messages that students could connect with.

Fedora’s support for diversity made a difference. We showed how Fedora welcomes people from all backgrounds, and that matched what many young Kenyans are looking for.

“The inclusive event organizing checklist showed me that Fedora cares about people, not just code.” – Joseph Mahihu

These words captured the energy in the room. This was about more than just tech. It was about finding a place to belong.

Many students asked questions about working in tech. Some were curious about whether open source experience could help them get jobs. The answer is yes. In Kenya, open source could be a stepping stone to careers in government, local businesses, or even self-employment. We discussed how students could contribute, gain experience, and then explore global remote opportunities or launch their own open projects.This was an unforgettable experience, and I can’t wait to see how this new wave of contributors shapes the future of Fedora in Kenya.

What’s next for Fedora in Kenya?

We’re not stopping here. This event started something. Here’s what’s next:

• June 21, 2025: Online workshop looking at documentation in Fedora. A planning guide is already in google docs to make this event impactful.
• Regular Fedora meetup in Nairobi, Kenya to track contributions and continue the momentum.

For more of my personal story, check out this blog post: How open communities shaped my journey and how Fedora can help grow local groups and highlights at this page.

Cornelius Emase, Outreachy applicant, community advocate, and Fedora contributor
My blog, X handle, Linkedin profile

Fedora test days are events where anyone can help make certain that changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the general public is also welcome at these events. If you’ve never contributed to Fedora Linux before, this is the perfect way to get started.

There are two overlapping test periods in the coming week.

• Monday 07 April through Friday, April 11, focuses on testing Fedora IoT .
• Tuesday 08 April through Tuesday, April 15, focuses on testing the GNOME 48 desktop and core applications.

Fedora IoT

For this test week, the focus is all-around; test all the bits that come in a Fedora IoT release as well as validate different hardware. This includes:

• Basic installation to different media
• Installing in a VM
• rpm-ostree upgrades, layering, rebasing
• Basic container manipulation with Podman.

We welcome all different types of hardware, but have a specific list of target hardware for convenience. This test week will occur Monday 07 April through Friday 11 April.

GNOME 48 Test Week

The Desktop/Workstation team is working on final integration for GNOME 48. This version was recently released, and will arrive soon in Fedora Linux. As a result, the Fedora desktop and Quality teams are organizing a test week from Tuesday, April 08, 2025 to Tuesday, April 15, 2025. The wiki page in this article contains links to the test images you’ll need to participate.

How does a test week work?

A test week is an event where anyone can help ensure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and everyone is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

• Download the test materials, which include some large files.
• Read and follow the directions step by step.

Happy testing and we hope to see you at one (or more!) of the test day events.