Tag: Fedora Atomic

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

Introducing Fedora CoreOS

The Fedora CoreOS team is excited to announce the first preview release of Fedora CoreOS, a new Fedora edition built specifically for running containerized workloads securely and at scale. It’s the successor to both Fedora Atomic Host and CoreOS Container Linux. Fedora CoreOS combines the provisioning tools, automatic update model, and philosophy of Container Linux with the packaging technology, OCI support, and SELinux security of Atomic Host.

Read on for more details about this exciting new release.

Why Fedora CoreOS?

Containers allow workloads to be reproducibly deployed to production and automatically scaled to meet demand. The isolation provided by a container means that the host OS can be small. It only needs a Linux kernel, systemd, a container runtime, and a few additional services such as an SSH server.

While containers can be run on a full-sized server OS, an operating system built specifically for containers can provide functionality that a general purpose OS cannot. Since the required software is minimal and uniform, the entire OS can be deployed as a unit with little customization. And, since containers are deployed across multiple nodes for redundancy, the OS can update itself automatically and then reboot without interrupting workloads.

Fedora CoreOS is built to be the secure and reliable host for your compute clusters. It’s designed specifically for running containerized workloads without regular maintenance, automatically updating itself with the latest OS improvements, bug fixes, and security updates. It provisions itself with Ignition, runs containers with Podman and Moby, and updates itself atomically and automatically with rpm-ostree.

Provisioning immutable infrastructure

Whether you run in the cloud, virtualized, or on bare metal, a Fedora CoreOS machine always begins from the same place: a generic OS image. Then, during the first boot, Fedora CoreOS uses Ignition to provision the system. Ignition reads an Ignition config from cloud user data or a remote URL, and uses it to create disk partitions and file systems, users, files and systemd units.

To provision a machine:

  1. Write a Fedora CoreOS Config (FCC), a YAML document that specifies the desired configuration of a machine. FCCs support all Ignition functionality, and also provide additional syntax (“sugar”) that makes it easier to specify typical configuration changes.
  2. Use the Fedora CoreOS Config Transpiler to validate your FCC and convert it to an Ignition config.
  3. Launch a Fedora CoreOS machine and pass it the Ignition config. If the machine boots successfully, provisioning has completed without errors.

Fedora CoreOS is designed to be managed as immutable infrastructure. After a machine is provisioned, you should not modify /etc or otherwise reconfigure the machine. Instead, modify the FCC and use it to provision a replacement machine.

This is similar to how you’d manage a container: container images are not updated in place, but rebuilt from scratch and redeployed. This approach makes it easy to scale out when load increases. Simply use the same Ignition config to launch additional machines.

Automatic updates

By default, Fedora CoreOS automatically downloads new OS releases, atomically installs them, and reboots into them. Releases roll out gradually over time. We can even stop a rollout if we discover a problem in a new release. Upgrades between Fedora releases are treated as any other update, and are automatically applied without user intervention.

The Linux ecosystem evolves quickly, and software updates can bring undesired behavior changes. However, for automatic updates to be trustworthy, they cannot break existing machines. To avoid this, Fedora CoreOS takes a two-pronged approach. First, we automatically test each change to the OS. However, automatic testing can’t catch all regressions, so Fedora CoreOS also ships multiple independent release streams:

  • The testing stream is a regular snapshot of the current Fedora release, plus updates.
  • After a testing release has been available for two weeks, it is sent to the stable stream. Bugs discovered in testing will be fixed before a release is sent to stable.
  • The next stream is a regular snapshot of the upcoming Fedora release, allowing additional time for testing larger changes.

All three streams receive security updates and critical bugfixes, and are intended to be safe for production use. Most machines should run the stable stream, since that receives the most testing. However, users should run a few percent of their nodes on the next and testing streams, and report problems to the issue tracker. This helps ensure that bugs that only affect certain workloads or certain hardware are fixed before they reach stable.

Telemetry

To help direct our development efforts, Fedora CoreOS performs some telemetry by default. A service called fedora-coreos-pinger periodically collects non-identifying information about the machine, such as the OS version, cloud platform, and instance type, and report it to servers controlled by the Fedora project.

No unique identifiers are reported or collected, and the data is only used in aggregate to answer questions about how Fedora CoreOS is being used. We prominently document that this collection is occurring and how to disable it. We also tell you how to help the project by reporting additional detail, including information that might identify the machine.

Current status of Fedora CoreOS

Fedora CoreOS is still under active development, and some planned functionality is not available in the first preview release:

  • Only the testing stream currently exists; the next and stable streams are not yet available.
  • Several cloud and virtualization platforms are not yet available. Only x86_64 is currently supported.
  • Booting a live Fedora CoreOS system via network (PXE) or CD is not yet supported.
  • We are actively discussing plans for closer integration with Kubernetes distributions, including OKD.
  • Fedora CoreOS Config Transpiler will gain more sugar over time.
  • Telemetry is not yet active.
  • Documentation is still under development.

While Fedora CoreOS is intended for production use, preview releases should not be used in production. Fedora CoreOS may change in incompatible ways during the preview period. There is no guarantee that a preview release will successfully update to a later preview release, or to a stable release.

The future

We expect the preview period to continue for about six months. At the end of the preview, we will declare Fedora CoreOS stable and encourage its use in production.

CoreOS Container Linux will be maintained until about six months after Fedora CoreOS is declared stable. We’ll announce the exact timing later this year. During the preview period, we’ll publish tools and documentation to help Container Linux users migrate to Fedora CoreOS.

Fedora Atomic Host will be maintained until the end of life of Fedora 29, expected in late November. Before then, Fedora Atomic Host users should migrate to Fedora CoreOS.

Getting involved in Fedora CoreOS

To try out the new release, head over to the download page to get OS images or cloud image IDs. Then use the quick start guide to get a machine running quickly. Finally, get involved! You can report bugs and missing features to the issue tracker. You can also discuss Fedora CoreOS in Fedora Discourse, the development mailing list, or in #fedora-coreos on Freenode.

Welcome to Fedora CoreOS, and let us know what you think!