29 Jan 2025

feedFedora People

Fedora Infrastructure Status: Updates and Reboots

29 Jan 2025 9:00pm GMT

24 Jan 2025

feedFedora People

Fedora Community Blog: Infra and RelEng Update – Week 04 2025

Fedora Community Blog's avatar

This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 20th January - 24th January 2025

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It's responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

The post Infra and RelEng Update - Week 04 2025 appeared first on Fedora Community Blog.

24 Jan 2025 10:00am GMT

Fedora Magazine: Update on hibernation in Fedora Workstation

Fedora Magazine's avatar

Goals and rationale

Hibernation stores the state of the whole operating system - the contents of memory used by the kernel and all programs - on disk. The machine is then completely powered off. Upon next boot, this state is restored and the old kernel and all the programs that were running continue execution.

Hibernation is nowadays used less often, because "suspend" - the state where CPU is powered down, but the contents of memory are preserved, works fine on most laptops and other small devices. But if the suspend is implemented poorly and it drains the battery too quickly, or if the user needs to completely power off the device for some reasons, hibernation can still be useful.

We need a storage area for hibernation. The kernel allows two options:
- either a single large-enough swap device, usually a partition,
- or a single large-enough swap file on some file system.

Fedora Linux installations by default do not use a normal swap device or file. Instead, a zram device is created, which is an in-memory compressed swap area. It is not suitable for hibernation. This means that hibernation does not work out-of-the-box on Fedora Linux. This guide describes how to create a swap file to enable hibernation.

Limitations

This method only works on UEFI!

To check that the system uses UEFI:

bootctl

If this commands prints "Not booted with EFI", then the method described below won't work. Refer to the original Hibernation in Fedora Workstation (for Fedora Linux 36) instead.

Another severe limitation is that SecureBoot must be disabled. The kernel does not allow hibernation with SecureBoot! Disabling SecureBoot reduces the security of the machine somewhat. Thus, do this only if you think that hibernation is more worth it.

Implementation

First, check whether Secure Boot is on:

bootctl

If this prints "Secure Boot: disabled" then SB is off. Otherwise, reboot the machine, go into UEFI settings, and disable Secure Boot.

Second, create and enable a swap file:

SWAPSIZE=$(free | awk '/Mem/ {x=$2/1024/1024; printf "%.0fG", (x<2 ? 2*x : x<8 ? 1.5*x : x) }')
sudo btrfs subvolume create /var/swap
sudo mkswap --file -L SWAPFILE --size $SWAPSIZE /var/swap/swapfile
sudo bash -c 'echo /var/swap/swapfile none swap defaults 0 0 >>/etc/fstab'
sudo swapon -av

This should print a message that swap was enabled on /var/swap/swapfile. The swap file is added to fstab, so it'll be permanently active. This is a good thing, it should make the system more reliable in general.

Now we are ready to test hibernation:

systemctl hibernate

After the system has shut down, boot it again and let one of the kernels start. The machine should return to the previous state from before hibernation.

This method does not require further configuration because systemd automatically stores the location of the swap file before entering hibernation in an UEFI variable, and then after the reboot, reads that variable and instruct the kernel to resume from this location. This only works on UEFI systems, but is otherwise quite simple and robust.

Reverting the changes

sudo swapoff -v /var/swap/swapfile
sudo sed -r -i '/.var.swap.swapfile/d' /etc/fstab
sudo btrfs subvolume rm /var/swap

After that, reenable SecureBoot if appropriate.

Troubleshooting

This process mail fail in two ways:

In both cases, the first step is to look at journalctl -b, in particular any error lines.

24 Jan 2025 8:00am GMT