Tag: news

Posted on by — Leave a comment

Fedora Verified: What Does the Community Think?

Introduction Earlier this year, the community was invited to share their thoughts on a potential new initiative called “Fedora Verified“. The goal of this survey was not to make final decisions, but to listen – to understand what contributors value, where opinions differ, and what questions still need answering.

This is a summary of what we found.

Note: Fedora Verified is still a conceptual idea under discussion by the Fedora Council. Nothing has been finalized. The Council plans to continue these conversations with the community in the coming months, including at Flock.

Who responded?

The survey received 90 fully completed responses from contributors across the Fedora community. We focused our analysis exclusively on these full responses to ensure we are looking at complete, thoughtful feedback.

What the community said

Key Takeaways – When we looked at the data, a few incredibly clear themes emerged regarding what contributors want this program to look like if it moves forward:

  • Code isn’t everything: This was the loudest piece of feedback. A massive 66% of respondents explicitly stated that all types of contributions – including documentation, design, event organization, and community support – must carry the exact same weight as code contributions.
  • Keep the door open for newcomers: Nearly 40% of respondents expressed concern that adding a “Verified” status might intimidate new contributors and make it harder for them to get started. Any future model needs a welcoming, clear on-ramp.
  • 12 months is too short: We proposed that the Verified status would expire after 12 months of inactivity. A majority (52%) rejected this, feeling that life gets in the way and a 12-month expiry is too strict.
  • Show us our progress: To help navigate the path to becoming Verified, 53% of respondents asked for a visual contribution tracking dashboard (similar to an enhanced Fedora Badges experience).

The Tension: Structure vs. Flexibility

The results also reveal two interesting and contrasting groups within the community regarding governance of the program.

A notable portion of contributors expressed a desire for more rigidity, wanting clearly defined milestones (43%) and formal committee reviews. At the same time, a similarly sizable group preferred less structure, with 62% asking for a moderately or lightly structured path, feeling that too much formality could discourage participation.

This tension was one of the most valuable findings of the survey. It shows that the Fedora Verified concept touches on something the community feels strongly about in different directions. Both perspectives are valid – setting clear expectations while leaving room for diverse contribution styles. The Council must achieve a careful balance as it moves forward.

What comes next?

These findings are being shared with the Fedora Council and relevant SIGs to inform future community conversations. The full analysis report, including a detailed breakdown of all survey responses, is available here: “Analysis Report.”

If you have thoughts or feedback on these findings, we’d love to hear from you on “Fedora Discussion.”

Posted on by — Leave a comment

How Fedora is responding to recent Kernel vulnerabilities

Banner showing a drawing of a padlock and the text "How Fedora is responding to recent Kernel vulnerabilities".

The last few weeks have seen a significant spike in reports of security vulnerabilities in the Linux Kernel. CopyFail, DirtyFrag, and Fragnesia have all exposed a path for a malicious user to escalate their privileges on a system from a standard user to root, and it’s possible there are more vulnerabilities that will be found. The Fedora Project is committed to keeping its users secure and patched against vulnerabilities as quickly as possible when they are disclosed, so let’s talk about how we try to do that.

Recent developments in machine learning have lead to a veritable gold rush for security researchers who can now rely on LLMs to analyze massive code bases like the Linux Kernel and find vulnerabilities at a rate well above what was previously possible. LLMs are also being used to weaponize these vulnerabilities once they’ve been found, allowing attackers to significantly shorten the gap between vulnerability disclosure and exploitation in the wild (source). All this means that it’s more important than ever for Fedora to have a robust process for tracking these vulnerabilities and distributing fixes for them.

What Fedora is doing

There are a number of ways the Fedora Package Maintainers get notified of new security vulnerabilities, the simplest of which is through security bulletins. Many projects post about their security updates on places like the oss-security mailing list and several Fedora contributors monitor these mailing lists for relevant vulnerabilities. The Red Hat Product Security team will also often raise Bugzilla bugs against Fedora packages for CVEs they are tracking, allowing Fedora to take advantage of the work being done to support RHEL customers.

Often security updates will flow through the usual Fedora package update process. Fedora uses tools like Anitya and Packit to monitor for new releases of upstream packages and automatically prepare updates for them. This automation helps across all updates with achieving Fedora’s “First” foundation, but they’re especially helpful for security updates which can be extremely time-sensitive to publish. If everything works as designed, by the time a human gets involved in preparing the update, there could already be a pull request and scratch build ready for testing.

Once the Fedora Package Maintainers are aware of a security vulnerability in a package we distribute, we’ll evaluate the best way to make the patch available to users of supported Fedora releases. Often this just means publishing the latest version of the package, but sometimes this isn’t possible. If the fix has not yet been merged in the upstream project (as happened with the recent kernel vulnerabilities) or if the latest version is too far from the current package version in that Fedora release (more information), the fix may be applied as a standalone patch. This can lead to a situation where a fixed version of the package is available but the version number still shows the vulnerable version, so you can use the dnf changelog command to check the update history for the package and see if a patch has been applied.

Keeping your system secure

It may sound cliché, but for most users the best thing you can do to keep your system secure is regularly updating it. Security package updates in Fedora are tagged with their severity and CVE numbers, so you can keep track of when security updates are published into Bodhi (for example). You can also apply all the pending security updates on your system using the following command:

dnf update --security

Some desktop environments will proactively notify users if there are pending security updates for their system. For example, GNOME Software will periodically check for pending updates and send the user a toast notification like the one below prompting to install the updates.

If you’d like to automate patching vulnerable packages, dnf-automatic can be configured to automatically download and apply security updates on a schedule, although applying kernel upgrades will require rebooting the system. You can learn more about this in the documentation here.

Getting involved

If this kind of Open Source security sounds interesting to you, why not consider becoming a Fedora contributor? We’re always looking for more people to get involved with projects like the Security SIG and Kernel Maintenance!

Posted on by — Leave a comment

Log Detective in Packit

Log Detective analysis is coming to Packit.

Starting this month, Log Detective will provide an analysis of failed Packit-triggered scratch Koji builds on dist-git pull-requests.

Packit will keep on doing what it’s good at, integrating upstream projects with downstream distributions.
Only now, it will have Log Detective to explain package build failures.

In Copr, the user can already request a Log Detective analysis by clicking on the “Ask AI” button.

In Packit, a build failure triggers a request for analysis automatically and presents the result in the dashboard, when it is ready.

The analysis does not require any additional setup. It is not necessary to choose which logs to send or to tune a prompt. Our service handles everything for you.

Log parsing and analysis derivation

Starting with version 4.0, the Log Detective works as an agent written in the BeeAI Framework.

The agent receives all logs and other build artifacts, as a part of the analysis request. Log Detective then uses a variety of tools, mostly based around the Drain template mining algorithm, to extract potentially useful snippets from the files. These snippets represent only a small fraction of the original log file size.

By extracting and using snippets, instead of entire original logs, we save tokens and limit the time needed for the analysis to finish. We also limit the amount of useless information in the model context.

This approach allows us to use even relatively small models and still get good results.

Communication architecture

Packit service handles failed Koji builds in the same way as before.
However, Packit now also requests an analysis of a failed build by sending a request to the Log Detective
interface server. The interface server, designed as a lightweight containerized service, handles all communication between the Log Detective and Packit services.

Packit sends a request for analysis to the Log Detective server. When the results are ready, the interface server posts them on the Fedora Messaging bus where Packit collects them.

Result presentation

An analysis from Log Detective consists of a statement of what, if anything, went wrong during the package build, and optionally, a suggestion of a solution. In the current configuration, Log Detective does not use sources other than build logs for the analysis.

Packit dashboard links Log Detective results to the PR that has triggered them.

Purpose and limitations

Since Log Detective uses a general purpose model, and lacks access to other information sources, it is obviously limited. Therefore it is not, and cannot be a substitute for years of experience in package maintenance in the Fedora ecosystem. If you have been building packages for a while, it probably has little to offer you.

It is intended to help those who don’t have such experience, and hopefully make their job a little easier.

Future development

Log Detective is under active development and we are looking into ways to improve it.
We are continually revising the Log Detective system prompt to improve response quality, while periodically comparing the overall performance against a selection of annotated build logs, which we are collecting on our website.

We also plan to reuse a select part of this dataset to create an additional information source for Log Detective, to further improve the quality of the analysis we provide.

In the future, we also plan to provide an analysis for Copr builds handled by Packit.

We are also considering ways of improving the presentation of an analysis, such as expanding the Packit dashboard results to include not only the final analysis, but also extracted log snippets that were used to derive it.

Posted on by — Leave a comment

Fedora Hummingbird: Taking the Hummingbird model to the full operating system

At Red Hat Summit 2026, we’re announcing Fedora Hummingbird — a new container-based rolling Fedora Linux distribution. This distribution provides access to the latest software as soon as it’s available upstream, which ensures that it’s up to date and secure.

Fedora Hummingbird primarily utilizes an image-based workflow, similar to containers, but also runs in virtual machines and even on bare metal. If you’ve been following Project Hummingbird‘s work on container images, or Project Bluefin’s work on the operating system, you already know the model. Fedora Hummingbird applies this model all the way down to the host OS.

The foundation for Fedora Hummingbird already ships today from the Hummingbird containers repository. You can pull and boot it right now.

What is Project Hummingbird?

The central goal of Project Hummingbird is to get as close to zero CVE reports as possible in every container image it ships, and to stay there continuously. The team made every architectural decision, including distroless images, minimal package footprints, hermetic builds, and the degree of pipeline automation, in service of that goal. “Distroless” means no package manager, no shell, just the application and what it strictly needs to run.

Why does this matter? When you pull a third-party container image today, you inherit its vulnerabilities and you’re on the hook for managing them. Pull a Hummingbird image and the team’s pipeline has already done the CVE triage, the patching, and the rebuild – you get to skip CVE hell. (If you’re curious, current CVE status across all images and variants is published live at the Hummingbird catalog).

Over the past eight months, the team has built a catalog of 49 unique minimal, hardened, distroless container images (that’s 157 variants including FIPS and multi-arch) covering Python, Go, Node.js, Rust, Ruby, OpenJDK, .NET, PostgreSQL, nginx, and dozens more. Distroless means no package manager, no shell, just the application and what it strictly needs to run.

How it’s built

The infrastructure behind this is a Konflux-based pipeline. It uses fully isolated, reproducible builds from pinned package lists, efficient incremental updates via chunkah (a tool the Hummingbird team built to ensure the system re-downloads only changed parts of an image), and continuous vulnerability scanning via Syft and Grype. When a vulnerability is patched upstream, the pipeline finds it, rebuilds, tests, and ships.

95%+ of the packages in every Hummingbird image come straight from Fedora Rawhide, unmodified. The build system pulls the remaining packages directly from upstream when Rawhide doesn’t yet carry them or isn’t new enough, and the team contributes changes back into Fedora. If that sounds like Fedora CoreOS, that’s because it’s a related idea, but serving a different use case. CoreOS is a minimal host for orchestrated workloads. Hummingbird serves developers who need to deploy multiple versions of runtimes (Python 3.11–3.14, Go 1.25–1.26, Node.js 20–25) in parallel and manage each version’s lifecycle independently.

The Hummingbird factory independently builds packages so they carry their own identity. This means each package can have a separate life cycle, patching policy, and CVE feed (specifically, a vulnerability feed that Red Hat’s Product Security team maintains). Every package ships with machine-readable vulnerability data that tells you not just which CVEs exist, but which ones actually affect your workload.

The OS as a container image

The challenges that Project Hummingbird seeks to address in userspace exist at the OS level as well, so we want to apply the same approach to addressing those challenges. This is where Fedora Hummingbird comes in. This image is already live at https://quay.io/repository/hummingbird-community/bootc-os. The team delivers this full Linux OS as an OCI image, and they build it using the same Konflux pipeline and hermetic RPM-locking approach as the rest of the Hummingbird catalog. Multi-arch: x86_64 and aarch64.

Under the hood, Fedora Hummingbird will use the ARK kernel (Always Ready Kernel) from the CKI project (already running in Fedora today) which tracks Linus’ mainline directly. The benefit of leveraging the CKI project is the curated kernel configuration and elaborate engineering framework that includes extensive testing around a fast-moving kernel stream.

The Fedora bootable containers initiative laid out the groundwork for all of this. The idea is that the OS is an OCI image, built and distributed like any other container, and updated atomically with rollback built in. No partial update states. No configuration drift. The root filesystem is read-only. Any writeable state lives in /var and /etc, cleanly separated from the OS content.

The Hummingbird bootc OS image boots today. What’s still in progress is the integration work. The image is currently a mix of Hummingbird-built RPMs and Fedora packages, and we’re working out how to bring the two closer together. That’s exactly the kind of work we’d love to collaborate on.

Hummingbird in the Fedora community

Many members of the Hummingbird team are already Fedora contributors and package maintainers – maintainers of Podman, and other container tools that Fedora and the broader Linux ecosystem depend on, as well as maintainers of Fedora CoreOS. Members of the Fedora community contributed the bootable containers work that underpins Fedora Hummingbird. Now those members are continuing the work as part of Hummingbird. Moving forward, we’d like to make Hummingbird a part of the Fedora Project so that it can benefit and grow within that same community.

The Hummingbird pipeline already builds and publishes a set of container images based entirely on Fedora Rawhide at quay.io/organization/hummingbird-rawhide. The team has already started bringing improvements back to Fedora. These include container-specific optimizations, bugs found in .spec files, and more. The vulnerability feed that ships with Hummingbird packages is something we think could benefit the broader Fedora ecosystem too.

Getting started

Here are some quick-start instructions for getting a virtual machine up and running:

1. Create the image

sudo podman run --rm --privileged --pull=newer \ --security-opt label=type:unconfined_t \ -v /tmp/bib-config.toml:/config.toml:ro \ -v /var/lib/libvirt/images:/output \ -v /var/lib/containers/storage:/var/lib/containers/storage \ quay.io/centos-bootc/bootc-image-builder:latest \ --type qcow2 --rootfs ext4 \ quay.io/hummingbird-community/bootc-os:latest

2. Rename the image

sudo mv /var/lib/libvirt/images/qcow2/disk.qcow2 \ /var/lib/libvirt/images/fedora-hummingbird.dc2.crunchtools.com \ && sudo rmdir /var/lib/libvirt/images/qcow2

3. Create a virtual machine

sudo virt-install --connect qemu:///system \ --name fedora-hummingbird.dc2.crunchtools.com \ --memory 4096 --vcpus 2 \ --disk /var/lib/libvirt/images/fedora-hummingbird.dc2.crunchtools.com,format=qcow2 \ --import --os-variant fedora-unknown \ --network network=default,model=virtio \ --graphics vnc --noautoconsole

Get involved

When you’re ready to try it, there’s no registration form, no subscription-manager, no entitlements required. The code is already there and the pipeline is already running — we’d love more eyes on it. Here’s how to jump in:

  • Try the image: You can find instructions on using the image on Quay
  • File issues and feedback: anything broken, missing, or surprising is worth reporting at this stage
  • Contribute: the project currently lives at gitlab.com/redhat/hummingbird/containers — establishing a home in Fedora’s own infrastructure is part of the work ahead
  • Join the conversation: visit the SIG page for info on our getting-started sessions.

Fedora has always been where the community proves out new Linux ideas before they matter everywhere else. Fedora Hummingbird is an experiment for image-based, continuously-maintained operating systems, and we think it’s ready for the community to kick the tires.

Posted on by — Leave a comment

Fedora Asahi Remix 44 is now available

We are happy to announce the general availability of Fedora Asahi Remix 44. This release brings Fedora Linux 44 to Apple Silicon Macs.

Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all of the exciting improvements brought by Fedora Linux 44.  Fedora Asahi Remix 44 also retires our vendored Mesa and virglrenderer packages. Users who have not already manually done so will be automatically transitioned to the upstream Mesa and virglrenderer packages provided by the upstream Fedora repositories.

Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience, with all of the new and exciting features brought by Fedora KDE Plasma Desktop 44.  Plasma Setup replaces the previous Calamares-based setup wizard, providing a Plasma-native experience for user account creation and system setup. Additionally, Plasma Login Manager is now the default greeter and session manager, replacing SDDM. This applies to new installs only; users upgrading from previous versions of Fedora Asahi Remix will not have their configuration changed.

A GNOME variant is also available, featuring GNOME 50, 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 42 or 43 can be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported; either KDE’s Plasma Discover or DNF’s System Upgrade command must 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.

Posted on by — Leave a comment

What’s New in Fedora KDE Plasma Desktop 44

Fedora has released Fedora KDE Plasma Desktop Edition 44 to the public.

The Fedora KDE Plasma Desktop Edition is suitable for many needs.  It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment.  It provides a selection of KDE applications that are simple by default, but powerful when needed.

KDE Plasma 6.6

The KDE community makes your life easier with the latest release of KDE Plasma. It builds upon the foundations of Plasma 6 to provide a seamless, friendly, and familiar experience.

Fedora KDE 44 ships with Plasma 6.6.4 featuring:

  • Custom global theme creation by saving the current theme setup
  • More options for using color accent in windows with tint intensity for window frames
  • Support for connecting to Wi-Fi networks by scanning QR codes
  • Per-application volume adjustment from the task manager
  • New grayscale filter for colorblindness correction
  • New screen magnifier feature that tracks the mouse pointer
  • New “Slow keys” and “reduced motion” settings
  • Spectacle can do OCR scanning of images to capture text
  • Per-window filter from screencast through the menu in the title bar

There’s so much more detail available in the Plasma 6.6 release announcement.

Fedora KDE 44 specific updates

Beyond just the updates included in KDE Plasma 6.6, there are some major new features with Fedora KDE on Fedora Linux 44.

  • Fresh installations now use the brand-new Plasma Setup and Plasma Login Manager. These provide a more cohesive and integrated experience from the moment the computer is powered on the first time. The installation process has been simplified. It now enables you to easily set up a computer with Fedora KDE Plasma Desktop for a friend or a loved one.
  • The on-screen keyboard uses the new Plasma Keyboard, providing a fresh and future-forward implementation for keyboard input.

Fedora Linux 44 general updates

Some broader changes in Fedora Linux also directly impact Fedora KDE Plasma Desktop Edition, notably:

  • PackageKit now uses version 5 of the DNF package manager as the backend.
  • Support for select Qualcomm-based laptops.
  • The /etc/pki/tls/cert.pem file no longer exists by default. This may impact some programs that expect this file to provide system CA certificates instead of leveraging behaviors built into cryptographic security libraries to offer this information.

Fedora Ready is ready for Fedora KDE

The Fedora KDE Plasma Desktop 44 edition is fully supported within the Fedora Ready program. Fedora KDE is actively engaging with hardware vendors to support Fedora KDE Plasma Desktop on their devices.

We are pleased to announce that Star Labs offers preinstalled Fedora KDE Plasma Desktop as an option for their portfolio of devices. As makers of computers with an open source ethos embedded into the core of their products with even open source firmware powered by Coreboot, they share many of the same principles the Fedora community values. This is a very exciting moment for Fedora KDE and we look forward to deepening our collaboration with Fedora Ready participants and extending to other vendors. If you are a vendor potentially interested in Fedora Ready, please reach out!

Wrap-up

The Fedora KDE SIG hopes that you’ll find the Fedora KDE Plasma Desktop 44 to be a wonderful experience. When you’re ready to try it, click here for download links and verification instructions. If you’d like to learn more, check out the Fedora KDE Plasma Desktop website.

Posted on by — Leave a comment

Sealed Fedora Atomic Desktop bootable container images

I’m happy to announce that we have sealed bootable container images ready for testing for the Fedora Atomic Desktops!

What are sealed bootable container images?

Sealed bootable container images include all the components needed to create a fully verified boot chain, from the firmware to the operating system composefs image. This relies on Secure Boot and thus only supports system booting with UEFI on x86_64 & aarch64.

The components are:

  • systemd-boot as bootloader
  • a Unified Kernel Image (UKI) which includes the Linux kernel, an initrd and the kernel command line
  • a composefs repository with fs-verity enabled. This is managed by bootc.

Both systemd-boot and the UKI are signed for Secure Boot. The images are test images so the components are not signed with the official keys from Fedora.

The main direct benefit that we will get from this support is that we will be able to enable passwordless disk unlocking using the TPM in a way that will be reasonably secure by default.

How do I test those images?

See the instructions at github.com/travier/fedora-atomic-desktops-sealed on how to give the pre-built container and disk images a try and how to build your own.

We welcome testing and feedback! Please see the list of known issues and report new issue at github.com/travier/fedora-atomic-desktops-sealed. We’ll redirect them as needed to the right upstream projects.

Beware, those are testing images. The root account does not have a password set and sshd is enabled, by default, to make debugging easier. The UKI and systemd-boot are signed for Secure Boot but, since those are test images, they are not signed with the official keys from Fedora. Don’t use those images in production.

Where can I get more details about how this works?

If you want to know more about how sealed images work (i.e. how we make bootable containers, UKI and composefs work together to create a verified boot chain), see the following presentations and documentation:

Thanks to all the contributors that made this possible, notably (but non exhaustively) from the following projects: bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah and systemd.

Posted on by — Leave a comment

What’s New for Fedora Atomic Desktops in Fedora Linux 44

Fedora Linux 44 has been released! 🎉 So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).

Changes for all Atomic Desktops

Issue tracker moved to the new Fedora forge

We have moved the cross-variants issue tracker to the new Fedora forge. This is the best place to file issues that impacts all variants or to coordinate work between all of them. If you have issues specific to a given desktop environment then we usually prefer to track them in each respective SIG trackers. These are available on the README for the atomic-desktops organization.

Unified documentation, hosted on the new forge

The unified documentation for all Atomic Desktops is finally live! Unfortunately the translations have not been migrated so we will need help to re-translate everything again, once the translation setup is ready with the new forge. It should be mostly copy/paste from the previous docs and this time we will only have to translate the docs once and not for every (new) variant.

See the tracking issue atomic-desktops#10.

Removal of FUSE version 2 libraries

FUSE version 2 has been deprecated and unmaintained for a while so we have removed it from the images. In practice, this means two things:

  • If you are using AppImages, some of them may not work anymore.
  • If you are using legacy backends with Plasma Vault on Kinoite, you need to migrate your data.

See the Fedora Change and the tracking issue atomic-desktops#50. The implications are detailed below.

AppImages and the FUSE 2 libraries

Some AppImages are still using an old AppImage runtime that relies on FUSE 2 libraries being available on the host. See the Discussion thread for examples on how to check the runtime of an AppImage.

If some of your AppImages do not work on Fedora Atomic Desktops 44, we recommend:

  • Looking for a Flatpak for the application and giving it another try. Consider helping upstream package their application as a Flatpak.
  • Reporting the issue upstream so that they are aware that they should use a newer runtime. Consider helping upstream with this as well.

EncFS or CryFS backends for Plasma Vaults are removed

KDE upstream no longer recommends using the EncFS nor CryFS backends for Plasma Vaults, notably because they rely on the FUSE 2 libraries. If you are using one of those backends, you should migrate your data to a new vault using the only maintained backend (gocryptfs). Ideally this should occur before the update to Fedora Linux 44. If you have already updated to Fedora Linux 44 and need access to your data, you can layer the needed packages (cryfs or fuse-encfs) using rpm-ostree install <package>, then migrate your data and finally reset the layers with rpm-ostree reset.

Dropping compatibility for pkla Polkit rules

Support for the legacy pkla Polkit rules format has been removed. It is unlikely that you were relying on support for those rules as most of the ecosystem has moved on to the new JavaScript based format.

See the Fedora Change and the tracking issue atomic-desktops#102.

What’s New in Silverblue

GNOME 50

Fedora Silverblue comes with the latest GNOME 50 release. For more details about the changes that occur alongside GNOME 50, see What’s New in Fedora Workstation 44 on the Fedora Magazine.

What’s New in Kinoite

KDE Plasma 6.6

Fedora Kinoite ships with Plasma 6.6, Frameworks 6.24 and Gear 25.12.

See also What’s New in Fedora KDE Plasma Desktop 44 in the Fedora Magazine.

KDE Plasma Login Manager replaces SDDM

The brand new Plasma Login Manager replaces SDDM to provide a more integrated experience with systemd and the KDE Plasma session.

See the Fedora Change.

Unified out of the box experience with KDE Plasma Setup (OEM installation)

Thanks to the new Plasma Setup, it is now possible to install the system with Anaconda with minimal configuration and then complete the installation on the first boot by creating a new user and selecting the timezone. This is great when you want to install Fedora Kinoite on a computer and don’t want to setup a user in advance.

See the Fedora Change.

What’s New in Sway Atomic

Nothing specific for this release.

What’s New in Budgie Atomic

Fedora Budgie Atomic comes with the latest 10.10.2 Budgie release. This release brings Wayland support to Budgie Atomic. See the 10.10 release announcement for more details.

What’s New in COSMIC Atomic

Fedora COSMIC Atomic comes with the latest 1.0.8 release of the COSMIC desktop. This is now considered stable.

Universal Blue, Bluefin, Bazzite and Aurora

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

As always, 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 drivers, extra media codec, out of tree kernel drivers, etc.).

What’s Next

Helping us with a few nasty bugs

If you have an interest in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term. We would greatly appreciate help with:

  • Fixing root mount options (atomic-desktops#72): This is a long standing and mostly invisible bug that impacts performance.
  • Moving away from nss-altfiles (atomic-desktops#108): This is another long standing source of issues that new users regularly face.

Sealed Fedora Atomic Desktop bootable container images

Sealed images are now ready for testing! See the other article for all the details.

Road map to Bootable Containers

A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users. You can look at the road map for this transition at atomic-desktops#26.

One of the tasks is to move away from our unmaintained installation ISO building scripts to the new image-builder tooling. This is planned for Fedora Linux 45 for the ostree variants and support for Bootable Container will follow right after.

Another task is to start building the Fedora Atomic Desktops Bootable Container images using the Fedora Konflux instance.

Where to reach us

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

Posted on by — Leave a comment

How to Rebase to Fedora Linux 44 on Silverblue

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 44 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 44, 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 has completed. After the restart you will end up in a new and shiny release of Fedora Linux 44. 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 44 using the terminal is easy. First, check if the 44 branch is available:

$ ostree remote refs fedora

You should see the following in the output:

fedora:fedora/44/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 44 branch.

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

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

How to roll back

If anything bad happens (for instance, if you can’t boot to Fedora Linux 44 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 44 and your system will start in that previous version rather than Fedora Linux 44. 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 44 and roll back. So why not do it today?

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 a rebase of Fedora Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 44?

Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version prior (41->42->43->44 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/44/x86_64/kinoite

Posted on by — Leave a comment

What’s New in Fedora Workstation 44

This article highlights a few noteworthy changes in the latest release of Fedora Workstation 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 50

Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility, to color management and remote desktop.

As part of the Digital Wellbeing initiative, new native Parental Controls let you set screen time limits and bedtimes directly from Settings.

Many of the applications that are installed by default on the Fedora Workstation have also seen improvements, from the Document Viewer to the File Manager and the Calendar.

To learn more about these and other changes, you can read the GNOME 50 release notes.

Wrap-up

Be sure to check out the Fedora Linux 44 Change Set wiki for even more details about all the features and changes that went into Fedora Linux 44. Use the Fedora Discussion forum or Fedora’s Matrix chat server if you want to converse with the Fedora community about this new release!