Posted on Leave a comment

Announcing the release of Fedora Linux 37 Beta

The Fedora Project is pleased to announce the immediate availability of Fedora Linux 37 Beta, the next step towards our planned Fedora Linux 37 release at the end of October.

Download the prerelease from our Get Fedora site:

Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for specific use cases like Computational Neuroscience

Beta Release Highlights

Fedora Workstation

Fedora 37 Workstation Beta includes a beta release of GNOME 43. (We expect the final GNOME 43 release in a few weeks.) GNOME 43 includes a new device security panel in Settings, providing the user with information about the security of hardware and firmware on the system. Building on the previous release, more core GNOME apps have been ported to the latest version of the GTK toolkit, providing improved performance and a modern look. 

Other updates

The Raspberry Pi 4 is now officially supported in Fedora Linux, including accelerated graphics. In other ARM news, Fedora Linux 37 Beta drops support for the ARMv7 architecture (also known as arm32 or armhfp).

We are preparing to promote two of our most popular variants: Fedora CoreOS and Fedora Cloud Base to Editions. Fedora Editions are our flagship offerings targeting specific use cases. 

In order to keep up with advances in cryptography, this release introduces a TEST-FEDORA39 policy that previews changes planned for Fedora Linux 39. The new policy includes a move away from SHA-1 signatures.

Of course, there’s the usual update of programming languages and libraries: Python 3.11, Perl 5.36, Golang 1.19, and more!

Testing needed

Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the test mailing list or in the #quality channel on Matrix (bridged to #fedora-qa on Libera.chat). As testing progresses, we track common issues on Ask Fedora.

For tips on reporting a bug effectively, read how to file a bug.

What is the Beta Release?

A Beta release is code-complete and bears a very strong resemblance to the final release. If you take the time to download and try out the Beta, you can check and make sure the things that are important to you are working. Every bug you find and report doesn’t just help you, it improves the experience of millions of Fedora Linux users worldwide! Together, we can make Fedora rock-solid. We have a culture of coordinating new features and pushing fixes upstream as much as we can. Your feedback improves not only Fedora Linux, but the Linux ecosystem and free software as a whole.

More information

For more detailed information about what’s new on Fedora Linux 37 Beta release, you can consult the Fedora Linux 37 Change set. It contains more technical information about the new packages and improvements shipped with this release.

Posted on Leave a comment

Manual action required to update Fedora Silverblue, Kinoite and IoT (version 36)

Due to an unfortunate combination of issues, the Fedora Silverblue, Kinoite and IoT variants that are running a version from 36.20220810.0 and later are no longer able to update to the latest version.

You can use these two commands to work around the bugs:

$ sudo find /boot/efi -exec touch '{}' ';'
$ sudo touch /etc/kernel/cmdline

Afterwards, you can update your system as usual with GNOME Software (on Silverblue) or via:

$ sudo rpm-ostree upgrade

These two issues are rooted in GRUB2 bugs that have only landed in Fedora and do not affect CentOS Stream 9 or RHEL. This also does not affect Fedora CoreOS for different reasons.

You can get more details about those issues in the tracker for Fedora Silverblue: https://github.com/fedora-silverblue/issue-tracker/issues/322

Posted on Leave a comment

The business case for supporting EPEL

EPEL stands for Extra Packages for Enterprise Linux. EPEL is a collection of packages built and maintained by the community for use in Red Hat Enterprise Linux (RHEL), CentOS Stream, and RHEL-like distributions like Rocky Linux and Alma Linux.

I am going to make the case that if you use EPEL as part of your organization’s infrastructure, you have an interest in keeping those packages available and as secure as they can be.

Who is this article for? I’m thinking of the team leads, managers, and directors in IT departments who make decisions about the tools their organizations have access to.

If you don’t use or know about EPEL, it’s likely that you don’t have to think about these things. In this case this article isn’t for you. However, it might contain ideas for promoting sustainable uses of free and open source software that you can apply to other situations that are more relevant to you.

Reason 1: Unmaintained packages may be removed from EPEL

Packages must be built and maintained for them to be available to the users of every distro. If someone isn’t doing the work of maintaining the packages, those packages become increasingly out of date. Eventually they may even be removed from the repository because of the security risk. This is avoidable as long as a package has a maintainer.

If you or someone in your organization is the maintainer of a package that you use, then you don’t have to worry about it falling by the wayside and potentially becoming a vulnerability. You get to make sure that the package stays in the repo, is up to date, and remains compatible with the rest of your infrastructure or deployments. Plain and simple.

Of course there needs to be room to manage bandwidth. How critical an application is to the operations of your organization defines how important it should be for you to make sure that either you maintain it or it is being looked after. XFCE may just be a nice-to-have for you, but Ansible might be mission critical.

Reason 2: You’re the first to have any security patches

Cyber threats continue to grow in number of exploits found and the speed at which they are exploited. Security is on every IT person’s mind. Patching vulnerabilities is something that increasingly can’t wait, and this extends to EPEL packages as well.

If you’re the maintainer for a required application, you have the ability to respond quickly to newly discovered vulnerabilities and protect your organization. Additionally, acting in your own self-interest now protects all the other organizations that also depend on that package.

Reason 3: Everyone else who uses that package can help you keep the package running well

As the maintainer of an application, others who also use the package will alert you of bugs as they arise. These are bugs that you may not have realized were there. Arguably it may not be critical to squash bugs that you don’t experience. However, by becoming the hub for feedback for that package, you will also be smoothing out the experience for your own users who may not have thought to report the bug. You benefit from crowd-sourcing quality control.

Reason 4: You can prepare for future releases before they come out

All future LTS releases of RHEL and RHEL-like distros will have their start as CentOS Stream. If you plan on migrating to a release that is represented by the current version of CentOS Stream, as the maintainer you can and should be building against it. This allows you to ensure continuity by packaging the application yourself for your next upgrade. You will know, ahead of time, whether your must-have packages will work in the latest release of your enterprise distro of choice.

Reason 5: You’re contributing to the long-term confidence in EPEL as a platform

The only reason we have packages in EPEL to begin with is because individuals are volunteering their time to maintain them. In a few cases you have companies committing resources to maintain packages but they are a small minority. If people don’t believe that EPEL will stick around for as long as RHEL releases, maintainers can lose steam or burnout. By committing resources to EPEL, you are shoring up confidence in the project – confidence that can encourage other organizations and people to invest in EPEL.

Potential solutions

If at this point you are thinking to yourself, “I would like to give back in some way, but what would that look like?”, here are some ideas. Some require lower commitment than others if you want to help but need to remain flexible about involvement.

  1. Maintain at least one package of the ones you use in your organization. The average maintainer looks after 10 packages, so covering at least one should be an easier hurdle to cross.
  2. If everything you use is already covered, find at least one package without a maintainer so that you can support other users just as other maintainers are supporting you.
  3. Report bugs for the packages you’re using.
  4. Request packages from older EPEL branches in newer EPEL branches, i.e. EPEL 9.
  5. Provide testing feedback for packages in the epel-testing repositories.
  6. Depending on the number and importance of packages you use, consider how much employee time you want to dedicate to EPEL maintenance.
  7. Integrate any EPEL maintenance you provide into the job descriptions of the responsible employees so that your team can continue being a responsible open source contributor into the future.

Become a package maintainer

You can start by checking out the Fedora documentation on how to become a package maintainer!

If you need support, or assistance getting started, help is available in the EPEL Matrix channel (with IRC bridge). Here are other ways to get in touch with the EPEL community.

Since you’ve made it this far…

Please take this quick survey about EPEL! We’re looking for feedback on how to improve EPEL in the future.

Here are additional resources you can check out on EPEL and how you can leverage it more.

What do you think?

Do you think these reasons are valid? Are there others you think should be mentioned? Do you disagree with this idea? Continue the conversation in the comments below or in the Fedora Discussion board!

Posted on Leave a comment

Manage containers on Fedora Linux with Podman Desktop

Podman Desktop is an open-source GUI application for managing containers on Linux, macOS, and Windows.

Historically, developers have been using Docker Desktop for graphical management of containers. This worked for those who had Docker Daemon and Docker CLI installed. However, for those who used Podman daemon-less tool, although there were a few Podman frontends like Pods, Podman desktop companion, and Cockpit, there was no official application. This is not the case anymore. Enter Podman Desktop!

This article will discuss features, installation, and use of Podman Desktop, which is developed by developers from Red Hat and other open-source contributors.

Installation

To install Podman Desktop on Fedora Linux, head over to podman-desktop.io, and click the Download for Linux button. You will be presented with two options: Flatpak and zip. In this example we are using Flatpak. After clicking Flatpak, open it in GNOME Software by double clicking the file (if you are using GNOME). You can also install it via the terminal:

flatpak install podman-desktop-X.X.X.flatpak

In the above command, replace X.X.X with the specific version you have downloaded. If you downloaded the zip file, then extract the archive, and launch the Podman Desktop application binary. You can also find pre-release versions by going to the project’s releases page on GitHub.

Features

Podman Desktop is still in its early days. Yet, it supports many common container operations like creating container images, running containers, etc. In addition, you can find a Podman extension under Extensions Catalog in Preferences, which you can use to manage Podman virtual machines on macOS and Windows. Futhermore, Podman Desktop has support for Docker Desktop extensions.

You can install such extensions in the Docker Desktop Extensions section under Preferences. The application window has two panes. The left narrow pane shows different features of the application and the right pane is the content area, which will display relevant information given what is selected on the left.

Podman Desktop 0.0.6 running on Fedora 36

Demo

To get an overall view of Podman Desktop’s capabilities, we will create an image from a Dockerfile and push it to a registry, then pull and run it, all from within Podman Desktop.

Build image

The first step is to create a simple Dockerfile by entering the following lines in the command line:

cat <<EOF>>Dockerfile
FROM docker.io/library/httpd:2.4
COPY . /var/www/html WORKDIR /var/www/html CMD ["httpd", "-D", "FOREGROUND"]
EOF

Now, go to the Images section and press the Build Image button. You will be taken to a new page to specify the Dockerfile, build context and image name. Under Containerfile path, click and browse to pick your Dockerfile. Under image name, enter a name for your image. You can specify a fully qualified image name (FQIN) in the form example.com/username/repo:tag if you want to push the image to a container registry. In this example, I enter quay.io/codezombie/demo-httpd:latest, because I have a public repository named demo-httpd on quay.io. You can follow a similar format to specify your FQIN pointing to your container registry (Quay, Docker Hub, GitHub Container Registry, etc.). Now, press Build and wait for the build to complete.

Push image

Once the build is finished, it’s time to push the image. So, we need to configure a registry in Podman Desktop. Go to Preferences, Registries and press Add registry.

Add Registry dialog

In the Add Registry dialog, enter your registry server address, and your user credentials and click ADD REGISTRY.

Now, I go back to my image in the list of images and push it to the repository by pressing the upload icon. When you hover over the image name that starts with the name of the registry added in the settings (quay.io in this demo), a push button appears alongside the image name.

The push button that appears when you hover over the image name
Image pushed to repository via Podman Desktop

Once the image is pushed, anyone with access to the image repository can pull it. Since my image repository is public, you can easily pull it in Podman Desktop.

Pull image

So, to make sure things work, remove this image locally and pull it in Podman Desktop. Find the image in the list and remove it by pressing the delete icon. Once the image is removed, click the Pull Image button. Enter the fully qualified name in the Image to Pull section and press Pull image.

Our container image is successfully pulled

Create a container

As the last part in our Podman Desktop demo, let us spin up a container from our image and check the result. I go to Containers and press Create Container. This will open up a dialog with two choices: From Containerfile/Dockerfile, and From existing image. Press From existing image. This takes us to the list of images. There, select the image we pulled.

Create a container in Podman Desktop

Now, we select our recently-pulled image from the list and press the Play button in front of it. In the dialog that appears, I enter demo-web as Container Name and 8000 as Port Mapping, and press Start Container.

Container configuration

The container starts running and we can check out our Apache server’s default page by running the following command:

curl http://localhost:8000 
It works!

You should also be able to see the running container in the Containers list, with its status changed to Running. There, you will find available operations in front of the container. For example, you can click the terminal icon to open a TTY into the container!

Display of running container demo-web in Podman Desktop with available operations for the container

What Comes Next

Podman Desktop is still young and under active development. There is a project roadmap on GitHub with a list of exciting and on-demand features including:

  • Kubernetes Integration
  • Support for Pods
  • Task Manager
  • Volumes Support
  • Support fo Docker Compose
  • Kind Support
Posted on Leave a comment

Contribute at the i18n, Release Validation, CrytoPolicy and GNOME 43 Final test weeks for Fedora Linux 37

There are 4 upcoming test days/weeks in the coming weeks. The first is Wed 31 August through Wed 07 Sept. It is to test Pre-Beta Release Validation. The second is Tuesday 6 Sept through Monday 12 Sept. It focuses on testing i18n. The third is Monday 5 Sept the Crypto Policy test day. The fourth is Wed 7 Sept through Wed 14 Sept to test GNOME 43 Final. Please come and test with us to make the upcoming Fedora 37 even better. Read more below on how to participate.

Pre-Beta Release Validation

Fedora Linux is foremost a community-powered distribution. Fedora Linux runs on all sorts of off-the-shelf hardware. The QA team relies on looking at bugs and edge cases coming out of community-owned hardware, so testing pre-release composes is a crucial part of the release process. We try to fix as many of them as we can! Please participate in the pre-beta release validation test week now through 7 September. You can help us catch those bugs at an early stage. A detailed post can be found here

GNOME 43 Final test week

GNOME is the default desktop environment for Fedora Workstation and thus for many Fedora users. As a part of the planned change, the GNOME 43 Final will land on Fedora which then will be shipped with Fedora Linux 37. To ensure that everything works fine The Workstation Working Group and QA team will have this test week Wed 7 Sept through Wed 14 Sept. Refer to the GNOME 43 test week wiki page for links and resources needed to participate.

i18n test week

i18n test week focuses on testing internationalization features in Fedora Linux. The test week is Tuesday 6 Sept through Monday 12 Sept.

StrongCryptoSettings3 test day

This is a new and unconventional test day. The change, however small, will have impacts across many areas and we want our users to spot as many bugs as we possibly can. The advice is to use exotic VPNs, proprietary chat apps, different email providers and even git workflows. These can be tested with some advice which can be found here. This test day is Monday 5 Sept.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public 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 download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about both test days is available on the wiki pages mentioned above. If you’re available on or around the days of the events, please do some testing and report your results.

Come and test with us to make the upcoming Fedora 37 even better.

Posted on Leave a comment

Help improve GNOME!

gnome-info-collect is a new tool that collects anonymous data about how GNOME systems are configured. It sends that information back to GNOME servers where it can be analyzed. The goal of this tool is to help improve GNOME, by providing data that can inform design decisions, influence where resources are invested, and generally help GNOME understand its users better.

The more people who provide data, the better! So, if you would like to help us improve GNOME, please consider installing and running gnome-info-collect on your system. It only takes a second.

As of last week, gnome-info-collect is ready to be used, and we are asking all GNOME users to install and run it!

How to run the tool

Simply install the package from Fedora Copr repository by running the following commands:

$ dnf copr enable vstanek/gnome-info-collect
$ dnf install gnome-info-collect

The Copr repository also contains instructions on how to install on systems without dnf (useful for Silverblue users).

After installing, simply run

$ gnome-info-collect

from the Terminal. The tool will show you what information will be shared and won’t upload anything until you give your consent.

There are packages for other distributions as well. See the project’s README for more information.

How it works

gnome-info-collect is a simple client-server application. The client can be run on any GNOME system. There, it collects various system data including:

  • Hardware information, including the manufacturer and model
  • Various system settings, including workspace configuration, and which sharing features are enabled
  • Application information, such as which apps are installed, and which ones are favourited
  • Which GNOME shell extensions are installed and enabled

You can find the full list of collected information in the gnome-info-collect README. The tool shows the data that will be collected prior to uploading and, if the user consents to the upload, is then securely sent to GNOME’s servers for processing.

Data privacy

The collected data is completely anonymous and will be used only for the purpose of enhancing usability and user experience of GNOME. No personal information, like usernames or email addresses, is recorded. Any potentially identifying information, such as the IP address of the sender and the precise time of receiving the data, is discarded on the server side. To prevent the same client from sending data multiple times, a salted hash of the machine ID and username is used.

All of this ensures that the collected data is confidential and untraceable.

Spread the word!

The best way to help is to take part by running gnome-info-collect and uploading your anonymous data.

You can also help by sharing this article with other GNOME users, and by encouraging others to run the collection tool themselves. The more users running gnome-info-collect, the better conclusions we can make from the collected data. This will result in an improved GNOME system that is more comfortable for its users.

So, do not hesitate to help improve GNOME. Simply install gnome-info-collect, run it and go tell all your GNOME friends about it! Thank you!

Posted on Leave a comment

Fedora Linux editions part 2: Spins

One of the nice things about using Linux is the wide choice of desktop environments. Fedora Linux official Worksation edition comes with GNOME as default desktop environment, but you can choose another desktop environment as default via Fedora Spins. This article will go into a little more detail about the Fedora Linux Spins. You can find an overview of all the Fedora Linux variants in my previous article Introduce the different Fedora Linux editions.


KDE Plasma Desktop

This Fedora Linux comes with KDE Plasma as the default desktop environment. KDE Plasma is an elegant desktop environment that is very easy to customize. Therefore, you can freely and easily change the appearance of your desktop as you wish. You can customize your favorite themes, install the widgets you want, change icons, change fonts, customize panels according to your preferences, and install various extensions from the community.

Fedora Linux KDE Plasma Desktop is installed with a variety of ready-to-use applications. You’re ready to go online with Firefox, Kontact, Telepathy, KTorrent, and KGet. LibreOffice, Okular, Dolphic, and Ark are ready to use for your office needs. Your multimedia needs will be met with several applications such as Elisa, Dragon Player, K3B, and GwenView.

Fedora KDE Plasma Desktop
Fedora KDE Plasma Desktop

More information is available at this link: https://spins.fedoraproject.org/en/kde/


XFCE Desktop

This version is perfect for those who want a balance between ease of customizing appearance and performance. XFCE itself is made to be fast and light, but still has an attractive appearance. This desktop environment is becoming popular for those with older devices.

Fedora Linux XFCE is installed with various applications that suit your daily needs. These applications are Firefox, Pidgin, Gnumeric, AbiWord, Ristretto, Parole, etc. Fedora Linux XFCE also already has a System Settings menu to make it easier for you to configure your Fedora Linux.

Fedora XFCE Desktop
Fedora XFCE Desktop

More information is available at this link: https://spins.fedoraproject.org/en/xfce/


LXQT Desktop

This spin comes with a lightweight Qt desktop environment, and focuses on modern classic desktops without slowing down the system. This version of Fedora Linux includes applications based on the Qt5 toolkit and is Breeze themed. You will be ready to carry out various daily activities with built-in applications, such as QupZilla, QTerminal, FeatherPad, qpdfview, Dragon Player, etc.

Fedora LXQt Desktop
Fedora LXQt Desktop

More information is available at this link: https://spins.fedoraproject.org/en/lxqt/


MATE-Compiz Desktop

Fedora Linux MATE Compiz Desktop is a combination of MATE and Compiz Fusion. MATE desktop allows this version of Fedora Linux to work optimally by prioritizing productivity and performance. At the same time Compiz Fusion provides a beautiful 3D look with Emerald and GTK + themes. This Fedora Linux is also equipped with various popular applications, such as Firefox, LibreOffice, Parole, FileZilla, etc.

Fedora Mate-Compiz Desktop
Fedora Mate-Compiz Desktop

More information is available at this link: https://spins.fedoraproject.org/en/mate-compiz/


Cinnamon Desktop

Because of its user-friendly interface, Fedora Linux Cinnamon Desktop is perfect for those who may be new to the Linux operating system. You can easily understand how to use this version of Fedora Linux. This spin has built-in applications that are ready to use for your daily needs, such as Firefox, Pidgin, GNOME Terminal, LibreOffice, Thunderbird, Shotwell, etc. You can use Cinnamon Settings to configure your operating system.

Fedora Cinnamon Desktop
Fedora Cinnamon Desktop

More information is available at this link: https://spins.fedoraproject.org/en/cinnamon/


LXDE Desktop

Fedora Linux LXDE Desktop has a desktop environment that performs fast but is designed to keep resource usage low. This spin is designed for low-spec hardware, such as netbooks, mobile devices, and older computers. Fedora Linux LXDE has lightweight and popular applications, such as Midori, AbiWord, Osmo, Sylpheed, etc.

Fedora LXDE Desktop
Fedora LXDE Desktop

More information is available at this link: https://spins.fedoraproject.org/en/lxde/


SoaS Desktop

SoaS stands for Sugar on a Stick. Fedora Linux Sugar Desktop is a learning platform for children, so it has a very simple interface that is easy for children to understand. The word “stick” in this context refers to a thumb drive or memory “stick”. This means this OS has a compact size and can be completely installed on a thumb drive. Schoolchildren can carry their OS on a thumb drive, so they can use it easily at home, school, library, and elsewhere. Fedora Linux SoaS has a variety of interesting learning applications for children, such as Browse, Get Books, Read, Turtle Blocks, Pippy, Paint, Write, Labyrinth, Physic, and FotoToon.

Fedora SOAS Desktop
Fedora SOAS Desktop

More information is available at this link: https://spins.fedoraproject.org/en/soas/


i3 Tiling WM

The i3 Tiling WM spin of Fedora Linux is a bit different from the others. This Fedora Linux spin does not use a desktop environment, but only uses a window manager. The window manager used is i3, which is a very popular tiling window manager among Linux users. Fedora i3 Spin is intended for those who focus on interacting using a keyboard rather than pointing devices, such as a mouse or touchpad. This spin of Fedora Linux is equipped with various applications, such as Firefox, NM Applet, brightlight, azote, htop, mousepad, and Thunar.

Fedora i3 Tiling WM
Fedora i3 Tiling WM

More information is available at this link: https://spins.fedoraproject.org/en/i3/


Conclusion

Fedora Linux provides a large selection of desktop environments through Fedora Linux Spins. You can simply choose one of the Fedora Spins, and immediately enjoy Fedora Linux with the desktop environment of your choice along with its ready-to-use built-in applications. You can find complete information about Fedora Spins at https://spins.fedoraproject.org/.

Posted on Leave a comment

4 cool new projects to try in Copr for August 2022

Copr is a build system for anyone in the Fedora community. It hosts thousands of projects for various purposes and audiences. Some of them should never be installed by anyone, some are already being transitioned to the official Fedora Linux repositories, and the rest are somewhere in between. Copr gives you the opportunity to install third-party software that is not available in Fedora Linux repositories, try nightly versions of your dependencies, use patched builds of your favorite tools to support some non-standard use cases, and just experiment freely.

If you don’t know how to enable a repository or if you are concerned about whether it is safe to use Copr, please consult the project documentation.

This article takes a closer look at interesting projects that recently landed in Copr.

Ntfy

Ntfy is a simple HTTP-based notification service that allows you to send notifications to your devices using scripts from any computer. To send notifications ntfy uses PUT/POST commands or it is possible to send notifications via ntfy CLI without any registration or login. For this reason, choose a hard-to guess topic name, as this is essentially a password.

In the case of sending notifications, it is as simple as this:

$ ntfy publish beer-lovers "Hi folks. I love beer!"
{"id":"4ZADC9KNKBse", "time":1649963662, "event":"message", "topic":"beer-lovers", "message":"Hi folks. I love beer!"}

And a listener who subscribes to this topic will receive:

$ ntfy subscribe beer-lovers
{"id":"4ZADC9KNKBse", "time":1649963662, "event":"message", "topic":"beer-lovers", "message":"Hi folks. I love beer!"}

If you wish to receive notifications on your phone, then ntfy also has a mobile app for Android so you can send notifications from your laptop to your phone.

Installation instructions

The repo currently provides ntfy for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable cyqsimon/ntfysh
sudo dnf install ntfysh

Koi

If you use light mode during the day but want to protect your eyesight overnight and switch to dark mode, you don’t have to do it manually anymore. Koi will do it for you!

Koi provides KDE Plasma Desktop functionality to automatically switch between light and dark mode according to your preferences. Just set the time and themes.

Installation instructions

The repo currently provides Koi for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable birkch/Koi
sudo dnf install Koi

SwayNotificationCenter

SwayNotificationCenter provides a simple and nice looking GTK GUI for your desktop notifications.

You will find some key features such as do-not-disturb mode, a panel to view previous notifications, track pad/mouse gestures, support for keyboard shortcuts, and customizable widgets. SwayNotificationCenter also provides a good way to configure and customize via JSON and CSS files.

More information on https://github.com/ErikReider/SwayNotificationCenter with screenshots at the bottom of the page.

Installation instructions

The repo currently provides SwayNotificationCenter for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable erikreider/SwayNotificationCenter
sudo dnf install SwayNotificationCenter

Webapp Manager

Ever want to launch your favorite websites from one place? With WebApp manager, you can save your favorite websites and run them later as if they were an apps.

You can set a browser in which you want to open the website and much more. For example, with Firefox, all links are always opened within the WebApp.

WebApp manager showcase

Installation instructions

The repo currently provides WebApp for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable perabyte/webapp-manager
sudo dnf install webapp-manager
Posted on Leave a comment

Contribute at the Fedora Kernel 5.19 and GNOME 43 Beta test weeks

There are two upcoming test weeks in the coming weeks. The first is Sunday 14 August through Sunday 21 August. It is to test Kernel 5.19. The second is Monday 15 August through Monday 22 August. It focuses on testing GNOME 43 Beta. Come and test with us to make the upcoming Fedora 37 even better. Read more below on how to participate.

Kernel test week

The kernel team is working on final integration for Linux kernel 5.19. This version was just recently released, and will arrive soon in Fedora. As a result, the Fedora kernel and QA teams have organized a test week Sunday, August 14, 2022 through Sunday, August 21, 2022. Refer to the wiki page for links to the test images you’ll need to participate.

GNOME 43 Beta test week

GNOME is the default desktop environment for Fedora Workstation and thus for many Fedora users. As a part of the planned change the GNOME 43 beta will land on Fedora which then will be shipped with Fedora 37. To ensure that everything works fine The Workstation Working Group and QA team will have this test week Monday 15 August through Monday 22 August. Refer to the GNOME 43 Beta test week wiki page for links and resources needed to participate.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public 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 download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about both test days is available on the wiki pages mentioned above. If you’re available on or around the days of the events, please do some testing and report your results.

Again, the two upcoming test days in the upcoming week are:

  • Kernel 5.19 testing on Sunday 14 August through Sunday 21 August
  • Gnome 43 Beta testing on Monday 15 August through Monday 22 August

Come and test with us to make the upcoming Fedora 37 even better.

Posted on Leave a comment

Hibernation in Fedora Workstation

This article walks you through the manual setup for hibernation in Fedora Linux 36 Workstation using BTRFS and is based on a gist by eloylp on github.

Goal and Rationale

Hibernation stores the current runtime state of your machine – effectively the contents of your RAM, onto disk and does a clean shutdown. Upon next boot this state is restored from disk to memory such that everything, including open programs, is how you left it.

Fedora Workstation uses ZRAM. This is a sophisticated approach to swap using compression inside a portion of your RAM to avoid the slower on-disk swap files. Unfortunately this means you don’t have persistent space to move your RAM upon hibernation when powering off your machine.

How it works

The technique configures systemd and dracut to store and restore the contents of your RAM in a temporary swap file on disk. The swap file is created just before and removed right after hibernation to avoid trouble with ZRAM. A persistent swap file is not recommended in conjunction with ZRAM, as it creates some confusing problems compromising your systems stability.

A word on compatibility and expectations

Hibernation following this guide might not work flawless on your particular machine(s). Due to possible shortcomings of certain drivers you might experience glitches like non-working wifi or display after resuming from hibernation. In that case feel free to reach out to the comment section of the gist on github, or try the tips from the troubleshooting section at the bottom of this article.

The changes introduced in this article are linked to the systemd hibernation.service and hibernation.target units and hence won’t execute on their own nor interfere with your system if you don’t initiate a hibernation. That being said, if it does not work it still adds some small bloat which you might want to remove.

Hibernation in Fedora Workstation

The first step is to create a btrfs sub volume to contain the swap file.

$ btrfs subvolume create /swap

In order to calculate the size of your swap file use swapon to get the size of your zram device.

$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100

In this example the machine has 16G of RAM and a 8G zram device. ZRAM stores roughly double the amount of system RAM compressed in a portion of your RAM. Let that sink in for a moment. This means that in total the memory of this machine can hold 8G * 2 + 8G of RAM which equals 24G uncompressed data. Create and configure the swapfile using the following commands.

$ touch /swap/swapfile
# Disable Copy On Write on the file
$ chattr +C /swap/swapfile
$ fallocate --length 24G /swap/swapfile
$ chmod 600 /swap/swapfile $ mkswap /swap/swapfile

Modify the dracut configuration and rebuild your initramfs to include the

resume

module, so it can later restore the state at boot.

$ cat <<-EOF | sudo tee /etc/dracut.conf.d/resume.conf
add_dracutmodules+=" resume "
EOF
$ dracut -f

In order to configure grub to tell the kernel to resume from hibernation using the swapfile, you need the UUID and the physical offset.

Use the following command to determine the UUID of the swap file and take note of it.

$ findmnt -no UUID -T /swap/swapfile
dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8

Calculate the correct offset. In order to do this you’ll unfortunately need gcc and the source of the btrfs_map_physical tool, which computes the physical offset of the swapfile on disk. Invoke gcc in the directory you placed the source in and run the tool.

$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c
$ ./btrfs_map_physical /path/to/swapfile FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET
0 regular 4096 2927632384 268435456 1 <4009762816>
4096 prealloc 268431360 2927636480 268431360 1 4009766912
268435456 prealloc 268435456 3251634176 268435456 1 4333764608
536870912 prealloc 268435456 3520069632 268435456 1 4602200064
805306368 prealloc 268435456 3788505088 268435456 1 4870635520
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888

The first value in the PHYSICAL OFFSET column is the relevant one. In the above example it is 4009762816.

Take note of the pagesize you get from getconf PAGESIZE.

Calculate the kernel resume_offset through division of physical offset by the pagesize. In this example that is 4009762816 / 4096 = 978946.

Update your grub configuration file and add the resume and resume_offset kernel cmdline parameters.

grubby --args="resume=UUID=dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8 resume_offset=2459934" --update-kernel=ALL

The created swapfile is only used in the hibernation stage of system shutdown and boot hence not configured in fstab. Systemd units control this behavior, so create the two units hibernate-preparation.service and hibernate-resume.service.

$ cat <<-EOF | sudo tee /etc/systemd/system/hibernate-preparation.service
[Unit]
Description=Enable swap file and disable zram before hibernate
Before=systemd-hibernate.service [Service]
User=root
Type=oneshot
ExecStart=/bin/bash -c "/usr/sbin/swapon /swap/swapfile && /usr/sbin/swapoff /dev/zram0" [Install]
WantedBy=systemd-hibernate.service
EOF
$ systemctl enable hibernate-preparation.service
$ cat <<-EOF | sudo tee /etc/systemd/system/hibernate-resume.service
[Unit]
Description=Disable swap after resuming from hibernation
After=hibernate.target [Service]
User=root
Type=oneshot
ExecStart=/usr/sbin/swapoff /swap/swapfile [Install]
WantedBy=hibernate.target
EOF
$ systemctl enable hibernate-resume.service

Systemd does memory checks on login and hibernation. In order to avoid issues when moving the memory back and forth between swapfile and zram disable some of them.

$ mkdir -p /etc/systemd/system/systemd-logind.service.d/
$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF
$ mkdir -p /etc/systemd/system/systemd-hibernate.service.d/
$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

Reboot your machine for the changes to take effect. The following SELinux configuration won’t work if you don’t reboot first.

SELinux won’t like hibernation attempts just yet. Change that with a new policy. An easy although “brute” approach is to initiate hibernation and use the audit log of this failed attempt via audit2allow. The following command will fail, returning you to a login prompt.

systemctl hibernate

After you’ve logged in again check the audit log, compile a policy and install it. The -b option filters for audit log entries from last boot. The -M option compiles all filtered rules into a module, which is then installed using semodule -i.

$ audit2allow -b
#============= systemd_sleep_t ==============
allow systemd_sleep_t unlabeled_t:dir search;
$ cd /tmp
$ audit2allow -b -M systemd_sleep
$ semodule -i systemd_sleep.pp

Check that hibernation is working via systemctl hibernate again. After resume check that ZRAM is indeed the only active swap device.

$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100

You now have hibernation configured.

GNOME Shell hibernation integration

You might want to add a hibernation button to the GNOME Shell “Power Off / Logout” section. Check out the extension Hibernate Status Button to do so.

Troubleshooting

A first place to troubleshoot any problems is through journalctl -b. Have a look around the end of the log, after trying to hibernate, to pin-point log entries that tell you what might be wrong.

Another source of information on errors is the Problem Reporting tool. Especially problems, that are not common but more specific to your hardware configuration. Have a look at it before and after attempting hibernation and see if something comes up. Follow up on any issues via BugZilla and see if others experience similar problems.

Revert the changes

To reverse the changes made above, follow this check-list:

  • remove the swapfile
  • remove the swap subvolume
  • remove the dracut configuration and rebuild dracut
  • remove kernel cmdline args via grubby –remove-args=
  • disable and remove hibernation preparation and resume services
  • remove systemd overrides for systemd-logind.service and systemd-hibernation.service
  • remove SELinux module via semodule -r systemd_sleep

Credits and Additional Resources

This article is a community effort based primarily on the work of eloylp. As author of this article I’d like to make transparent that I’ve participated in the discussion to advance the gist behind this but many more minds contributed to make this work. Make certain to check out the discussion on github.

There are already some ansible playbooks and shell scripts to automate the process depicted in this guide. For example check out the shell scripts by krokwen and pietryszak or the ansible playbook by jorp

See the arch wiki for the full guide on how to calculate the swapfile offset.