LifeBytes Journal

By the end of this guide the reader will be able to identify a Btrfs‑based Fedora installation, boot from a live USB, list and restore snapshots using the graphical utilities btrfs‑assistant and snapper, and verify that the system returns to a functional state without resorting to the command line.

Understanding the Btrfs Layout Used by Fedora

Fedora Workstation and Fedora KDE install the root filesystem as a single Btrfs partition that contains two default sub‑volumes. One sub‑volume holds the traditional “/” hierarchy, while the second is dedicated to /var/lib/machines. The latter exists to keep container images out of snapshot operations; it remains empty on systems that do not run virtual machines. Because Btrfs stores data in sub‑volumes rather than separate partitions, a snapshot captures the state of an entire sub‑volume at a point in time.

The installer (Anaconda) automatically registers these sub‑volumes with the snapper service. Snapper maintains a series of read‑only snapshots under /var/lib/snapper. Each snapshot is identified by a numeric ID and a timestamp, and snapper tracks the parent‑child relationship to enable incremental rollbacks.

Verifying the Btrfs Filesystem and Sub‑Volumes

Before attempting any recovery, confirm that the installed system uses Btrfs and that the expected sub‑volumes are present. The following read‑only command lists the filesystem type for each block device:

lsblk -f

In the output, the FSTYPE column should show btrfs for the root partition (typically /dev/sda2 or similar). To enumerate sub‑volumes on that partition, mount the partition in read‑only mode from a live environment and run:

sudo mount -o ro /dev/sda2 /mnt

Then list sub‑volumes with:

btrfs subvolume list /mnt

The command will display entries such as:

ID 256 gen 12345 top level 5 path @
ID 257 gen 12346 top level 5 path @/.snapshots

The @ sub‑volume corresponds to the root filesystem, while @/.snapshots holds the snapper snapshots. If the /var/lib/machines sub‑volume exists, it will appear with a distinct path under the mount point.

Preparing a Live USB with GUI Tools

Fedora’s official live ISO includes the necessary drivers and utilities to access Btrfs partitions. Create a bootable USB stick using any standard Fedora ISO image. The creation process must not alter the target system’s disks; it only writes to the removable media.

After booting the live environment, install the graphical snapshot manager packages if they are not already present. Both GNOME Software and KDE Discover can perform this step, but the command line provides a reproducible method:

sudo dnf install btrfs-assistant snapper

The btrfs-assistant package adds a GNOME/KDE integration layer that presents snapper snapshots within the file manager. The snapper package provides the underlying snapshot management service.

Starting the Snapper Service in the Live Environment

When running from a live USB, the snapper daemon is not started automatically. Enable it for the current session with:

sudo systemctl start snapperd.service

This command launches the snapper daemon, which reads the snapshot metadata from the mounted Btrfs partition. The service runs only in the live session and will terminate when the system reboots.

Using the GUI to Browse and Restore Snapshots

With the live environment running and the Btrfs partition mounted (typically at /run/media/liveuser/ROOT), open the file manager. The integration added by btrfs-assistant displays a virtual folder named .snapshots inside the root view. Each entry corresponds to a snapper snapshot and is labeled with its numeric ID and creation date.

To restore a snapshot, follow these steps:

1. Identify the snapshot that represents a known-good system state. The timestamps shown in the folder names help select the appropriate point.
2. Right‑click the snapshot folder and choose “Mount” (or “Open”). This action mounts the snapshot read‑only at a temporary location, typically under /run/media/liveuser/.snapshots.
3. Copy the contents of the mounted snapshot back to the original root sub‑volume. Because the live environment is operating on a separate disk, the copy operation does not affect the live system.

The copy operation can be performed with the graphical file manager’s drag‑and‑drop interface, or, for precision, with a read‑only rsync command that preserves permissions:

sudo rsync -aAX --delete /run/media/liveuser/.snapshots/ID/snapshot/ /mnt/

Replace ID with the numeric identifier of the chosen snapshot. The --delete flag ensures that files removed after the snapshot are also removed, reproducing the exact state of the system at the snapshot time. This operation overwrites the current root filesystem; to reverse it, repeat the process with a later snapshot or with a fresh backup of the current state.

Verifying the Restored System

After the copy completes, unmount the live USB’s root mount point and reboot into the restored installation:

sudo umount /mnt
sudo reboot

If the boot proceeds without errors, the restoration succeeded. Should the system still fail to boot, repeat the process with an earlier snapshot. Because each snapshot is independent, the administrator can iterate until a functional state is reached.

Trade‑offs and Operational Considerations

The GUI‑based recovery workflow offers several advantages for administrators accustomed to graphical environments:

• Ease of use: No need to memorize complex btrfs command syntax; the file manager presents snapshots as ordinary folders.
• Safety: Operations are performed from a live USB, keeping the installed system offline and preventing accidental writes during recovery.
• Visibility: Snapshots are labeled with timestamps, making it straightforward to select the correct point in time.

However, the approach also has limitations that must be weighed against alternative methods:

• Disk space consumption: Snapper retains multiple read‑only snapshots; each snapshot consumes additional space proportional to the amount of changed data. Administrators should monitor /var/lib/snapper and prune old snapshots with snapper delete when necessary.
• Performance impact: Frequent snapshot creation can introduce write amplification on SSDs. Fedora’s default configuration balances snapshot frequency with system load, but workloads with intensive write patterns may require tuning.
• Recovery granularity: The GUI restores an entire sub‑volume. For targeted file recovery, the command line btrfs subvolume snapshot or direct mounting of a specific snapshot may be more appropriate.
• Dependency on snapper: The graphical integration relies on snapper’s metadata. If snapper’s database becomes corrupted, the GUI will not display snapshots, and manual btrfs commands will be required to reconstruct the snapshot list.

In environments where headless recovery is required, administrators can fall back to the command‑line equivalents: list snapshots with snapper list, mount a snapshot with btrfs subvolume snapshot -r, and restore using rsync or cp -a. The GUI workflow described above simply abstracts these steps into a point‑and‑click process while preserving the same underlying mechanisms.

Source: fedoramagazine.org

By the end of this article readers will understand the architectural shift of the Fedora Badges service, the user‑interface improvements it introduces, and the practical implications for administrators and developers who maintain or integrate with the platform.

From Server‑Rendered Pages to a Single‑Page Application

The Fedora Badges application has been completely rewritten, replacing the legacy server‑rendered architecture with a modern single‑page application (SPA). This transition eliminates full‑page reloads for navigation and content updates, resulting in a markedly faster and more responsive user experience. Because the SPA runs entirely in the browser, the back‑end now serves JSON APIs rather than HTML fragments, allowing the front‑end to render data dynamically.

For system administrators, the move to an API‑centric back‑end simplifies scaling. Stateless API endpoints can be load‑balanced behind a reverse proxy, and horizontal scaling becomes a matter of adding more application instances without worrying about session affinity. Existing bookmarked URLs continue to function through server‑side redirects, preserving user workflows while the underlying delivery mechanism changes.

Responsive Design and Theming Flexibility

The new interface adapts to a variety of screen sizes and device types, employing responsive design techniques that automatically adjust layout components. Users can now select from eight distinct colour schemes, with the chosen palette applied consistently across navigation bars, borders, charts, and accent elements. The application also respects system‑level dark‑mode preferences while providing a manual toggle, ensuring accessibility across diverse environments.

Theme selections are stored in session storage, meaning the preferences persist for the duration of a browser session. Administrators should be aware that this storage mechanism does not survive a browser restart, which may affect users who expect long‑term theme persistence. Should a longer‑term solution be required, the back‑end could be extended to associate theme choices with user profiles.

Enhanced Visualisation of Badge Data

The profile page now includes a radar chart that visualises a user’s badge distribution across predefined categories. This chart offers a quick assessment of contribution diversity, highlighting under‑explored areas. The history page adds a timeline chart that aggregates badge‑earning activity over months and years, both for the individual and for linked friends. These visualisations rely on client‑side charting libraries that consume the same JSON payloads used for other UI components.

From a development standpoint, the inclusion of these charts demonstrates a shift toward richer client‑side data processing. Backend developers must ensure that API responses contain the necessary categorical breakdowns and timestamps, while front‑end developers need to maintain the charting logic as the underlying data model evolves.

Comparative and Social Features

A refreshed “difference” page enables users to compare their badge collections with those of friends, identifying shared badges, unique achievements, and missing items. This comparative view encourages collaborative learning and mentorship by surfacing potential partners based on complementary badge sets.

The platform also introduces a mentorship outreach mechanism, allowing users to contact community members whose badge profiles suggest expertise in desired contribution areas. While the source does not detail the communication channel, the feature implies an integration point for messaging or email services that administrators may need to configure or secure.

Rarity‑Based Badge Browsing

Each active badge now carries a rarity tier derived from the number of users who have earned it. The UI permits browsing badges by these tiers, making it straightforward to locate less common achievements. This rarity metadata is generated server‑side and exposed via the API, enabling developers to build custom queries or filters based on badge scarcity.

For administrators, the rarity calculation introduces a new data aggregation requirement. Depending on the size of the user base, periodic recomputation may be necessary to keep rarity tiers accurate. Implementing this as a background job or scheduled task can offload the computation from real‑time request handling, preserving API responsiveness.

Unified Search with Asynchronous Triggers

The search bar now performs a unified lookup across both badges and users. Results appear dynamically as the user types, but the asynchronous request is only triggered after four characters have been entered. This threshold reduces unnecessary load on the back‑end while still providing an interactive experience.

From an operational perspective, the search endpoint must handle partial matches efficiently. Indexing strategies—such as full‑text indexes on badge names and user identifiers—become critical to maintain low latency. Administrators should monitor query performance, especially as the dataset grows, and adjust indexing or caching configurations accordingly.

Customizable Leaderboard Periods

The rankings page has been expanded to accept custom time‑range filters, supporting days, weeks, months, and years. Users can now view leaderboard snapshots for any chosen interval, facilitating analysis of short‑term bursts or long‑term trends in badge acquisition.

Deterministic ranking results are generated based on the filtered dataset, and the resulting URLs can be shared. This shareability implies that the ranking view is stateless and reproducible given the same query parameters, a property that simplifies caching strategies and reduces server load for repeated accesses.

Operational Impact and Integration Considerations

The architectural overhaul to an SPA with JSON APIs alters the integration surface for external tools. Scripts or services that previously scraped server‑rendered HTML must now consume structured API endpoints. Documentation updates will be required to reflect endpoint URLs, request parameters, and response schemas.

Authentication mechanisms are not described in the source, but the shift to API‑driven interactions typically encourages token‑based authentication (e.g., OAuth2 or JWT). Administrators should verify that existing authentication flows are compatible with the new endpoints and that token revocation policies are enforced.

Logging and monitoring also need adjustment. Front‑end errors now surface as JavaScript console messages, while back‑end issues appear in API logs. Correlating user‑reported problems with server logs will require consistent request identifiers passed through both layers.

Summary of Changes for Stakeholders

* System administrators gain a more scalable, stateless back‑end architecture, but must adapt monitoring, logging, and indexing to support the new API patterns.

* Developers receive a richer client‑side environment with dynamic charts, theme persistence, and unified search, demanding careful handling of data contracts and front‑end state management.

* Power users benefit from faster navigation, responsive design, customizable themes, and new social features that promote mentorship and badge discovery.

Overall, the Fedora Badges service transition reflects a broader trend in web applications toward client‑heavy, API‑driven designs. The technical choices made—session storage for UI preferences, rarity tier calculations, and asynchronous search thresholds—balance user experience with server resource considerations. Administrators and developers who align their operational practices with these design principles will be positioned to support a responsive, maintainable badge platform as the Fedora community continues to grow.

Source: fedoramagazine.org

By the end of this article readers will understand how Fedora 45’s scheduled test days structure community validation of major system components, what technical areas are being exercised, and how administrators can contribute reliable feedback to improve the upcoming release.

Why Fedora 45 Needs More Than Automated CI

Fedora’s development process relies heavily on continuous integration pipelines that automatically compile packages, run unit tests, and verify known code paths. While these mechanisms catch regressions in controlled scenarios, they cannot guarantee that the new boot.iso image boots on every laptop model, that enforced RPM signature checks do not interfere with niche workflows, or that peripheral drivers behave correctly under real‑world usage. The upcoming Fedora 45 release introduces several foundational updates—new GNOME 51 desktop components, RPM 6.1 enhancements, updated installation media, and upcoming KDE 6.7—each touching large portions of the stack. Because these changes affect boot loaders, package management, display servers, and localization frameworks, the Fedora QA team has opened “test days” that invite the broader community to run targeted test cases on physical hardware and virtual machines.

Structure of the Test‑Day Program

The test‑day model is organized around short, focused windows during which developers, QA engineers, and volunteers converge on a single change area. Each window is announced on the Fedora test‑days portal and is linked to a dedicated wiki page that lists concrete test cases. Participants are encouraged to use a Fedora account to submit results through the test‑day web application, which is itself open source and hosted on the Fedora Forge. Communication during the events occurs primarily on Matrix channels identified by tags such as #test-day:fedoraproject.org and specific hashtags (e.g., #GNOME_51_Desktop).

The schedule for the current cycle includes:

• GNOME 51 Desktop – 17 – 21 August: validation of the desktop environment, graphics stack, peripheral handling, and core applications.
• I18n Test Week – 7 – 13 September: coverage of input methods, locale data, and keyboard layout handling.
• RPM 6.1 – focus on NSS‑based user/group lookups, transaction‑time queries, new macro modifiers, and enhanced rpmkeys output.
• Installation Media – booting the new boot.iso and live images on diverse hardware and virtual platforms.
• KDE 6.7, Cockpit, GRUB EFI / Confidential Computing – each slated for a dedicated test day or grouped under broader hardware‑specific sessions.

The list remains open; additional components such as kmscon, OpenSSL 4.0, CoreOS, and Kernel 7.2 are under consideration. This flexible approach allows maintainers of large‑impact packages to propose ad‑hoc test days by filing tickets on the Fedora Forge and tagging them appropriately.

Technical Focus Areas and Their Impact

GNOME 51 Desktop Validation

GNOME 51 introduces updates to the Mutter compositor, Wayland session handling, and a suite of core applications. Because the desktop environment interacts directly with graphics drivers (NVIDIA, AMD, Intel), display managers, and input devices, test participants are asked to verify suspend/resume cycles, external monitor handling, and GPU‑accelerated rendering. Successful validation ensures that the default Fedora workstation experience remains stable across the wide range of laptops and workstations used by the community.

RPM 6.1 Enhancements

RPM 6.1 adds support for NSS‑backed user and group lookups, enabling queries against directory services during package transactions. It also introduces new macro modifiers that affect how spec files are interpreted, and improves the verbosity of rpmkeys verification output. Since RPM underpins every package installation, upgrade, and removal operation, any regression could affect system integrity. Testers are instructed to perform typical package management workflows—installing, updating, and removing packages—while observing the new verification messages and ensuring that NSS queries resolve correctly in environments that rely on external authentication sources.

Installation Media and Boot.iso

The boot.iso and accompanying live images are the primary entry points for new Fedora installations. The test day for installation media asks participants to boot the images on both physical hardware and virtual machines, checking for successful hardware detection, installer functionality, and live environment stability. Particular attention is given to Wi‑Fi provisioning, disk partitioning, and the ability to transition from the live session to a fully installed system without errors. Feedback from these tests directly influences the final release media, reducing the likelihood of installer failures for end users.

KDE 6.7 and Cockpit Sessions

Although the KDE test day is still being finalized, the inclusion of KDE 6.7 reflects Fedora’s commitment to providing a first‑class KDE Plasma experience. Testers will focus on the KDE framework, Plasma desktop, and associated system settings tools. The Cockpit test day, scheduled after a multi‑year hiatus, will examine the web‑based management interface’s ability to monitor services, manage storage, and handle user sessions across the updated stack.

GRUB EFI and Confidential Computing

GRUB’s EFI support and emerging confidential computing features are hardware‑specific concerns. The associated test day targets platforms that expose EFI firmware interfaces and those capable of running enclaves or other trusted execution environments. Participants with compatible hardware are encouraged to verify that the bootloader correctly loads the Fedora kernel, respects Secure Boot policies, and that any confidential computing extensions function as documented.

How Administrators Can Contribute Effectively

To participate, an administrator must have a Fedora account, which grants access to the test‑day web application and the relevant Matrix channels. The typical workflow consists of selecting an active test day from the schedule, reviewing the wiki‑hosted test cases, and executing them on a chosen platform—either a virtual machine for general cases or a physical system for hardware‑specific scenarios. After completing a test case, the participant records observations—success, failure, or unexpected behavior—through the web interface. If an anomaly is detected, the developer community is available on Matrix to assist with debugging, and the issue can be escalated to a bug report if necessary.

Administrators who maintain packages that undergo substantial changes in Fedora 45 are also invited to propose dedicated test days. This is done by filing a ticket on the Fedora Forge, tagging it with “test days,” and describing the intended test scope. By aligning package‑level changes with community testing, maintainers can surface regressions early and ensure that downstream distributions receive a stable foundation.

Practical Implications for Fedora Deployments

The structured test‑day approach provides several concrete benefits for production environments. First, it expands the test surface beyond automated pipelines, capturing edge‑case interactions that only manifest on specific hardware or in unique workflow configurations. Second, the real‑time feedback loop between testers, developers, and QA engineers accelerates issue resolution, reducing the time between regression detection and patch release. Third, the open nature of the test‑day app and its underlying ticketing system ensures transparency; administrators can trace reported problems, view discussion threads, and verify that fixes are incorporated before the final release.

For organizations that rely on Fedora as a workstation or server platform, participating in test days can be a low‑cost way to validate upcoming changes against their own hardware inventories. By running the prescribed test cases on representative machines, sysadmins can anticipate potential disruptions—such as installer failures on particular BIOS configurations or RPM signature verification issues in custom repository setups—and plan mitigations ahead of the official rollout.

In summary, Fedora 45’s test‑day program operationalizes community testing for high‑impact components, turning a broad user base into an extension of the QA process. Administrators and developers who engage with these events gain early insight into system behavior, contribute to a more stable release, and help shape the future reliability of the Fedora ecosystem.

Source: fedoramagazine.org

By the end of this guide the reader will be able to install the Performance Co‑Pilot (PCP) SMART agent on Fedora, verify that drive health metrics are being collected, query key SMART attributes, and integrate the data into a Grafana dashboard for long‑term analysis.

Understanding PCP and the SMART PMDA

Performance Co‑Pilot (PCP) is an open‑source framework that provides a unified interface for collecting, storing, and visualizing system performance metrics. Metrics are exposed through Performance Metrics Domain Agents (PMDAs), each responsible for a specific subsystem. The pcp-pmda-smart package supplies a PMDA that reads SMART data from block devices and presents it as PCP metrics.

SMART (Self‑Monitoring, Analysis and Reporting Technology) is embedded in modern HDDs, SSDs, and NVMe devices. It continuously records parameters such as temperature, wear‑leveling count, error rates, and power‑on hours. When accessed through a single‑shot tool like smartctl, the data represents a snapshot. The PCP SMART PMDA, however, polls the device at regular intervals, stores the values in the PCP repository, and enables historical trend analysis.

Installing and Enabling the PCP SMART Agent

The required components are the core PCP daemon (pcp) and the SMART PMDA (pcp-pmda-smart). Installation uses Fedora’s package manager:

sudo dnf install pcp pcp-pmda-smart

The pcp-pmda-smart package installs the PMDA files under /var/lib/pcp/pmdas/smart/. To register the agent with the PCP collector daemon, run the installer script provided in that directory:

cd /var/lib/pcp/pmdas/smart/
sudo ./Install

The installer prompts for configuration options such as the polling interval and the list of devices to monitor. Accepting the defaults configures the agent to scan all block devices that expose SMART data. The installation creates a systemd unit (pmcd) that runs the collector daemon.

Start the collector immediately and enable it to start on boot:

sudo systemctl start pmcd
sudo systemctl enable pmcd

If the daemon needs to be stopped or disabled, use the corresponding systemd commands (systemctl stop pmcd and systemctl disable pmcd). The configuration files remain unchanged, allowing a quick re‑enable later.

Verifying Metric Availability

PCP provides the pminfo utility to list available metrics. To confirm that SMART metrics are being exported, query the metric namespace:

pminfo -t smart

A successful output lists metric identifiers such as smart.attributes.temperature_celsius.value for SATA/SAS drives and smart.nvme_attributes.temperature_sensor_one for NVMe devices. If no SMART metrics appear, verify that the SMART PMDA is enabled in /etc/pcp/pcp.conf and that the collector daemon is running.

Key SMART Metrics for Drive Health

While the SMART namespace contains dozens of attributes, a small subset provides the most actionable insight for proactive maintenance:

• Temperature – smart.attributes.temperature_celsius.value (SATA/SSD) or smart.nvme_attributes.temperature_sensor_one (NVMe). Sustained temperatures above 60 °C for HDDs and 70 °C for SSD/NVMe indicate inadequate cooling.
• Wear Leveling – NVMe devices expose a wear percentage through smart.nvme_attributes.media_and_data_integrity_errors or similar attributes; increasing values over months signal approaching endurance limits.
• Reallocated Sectors / Bad Blocks – For HDDs, the smart.attributes.reallocated_sector_ct counter increments when the drive remaps defective sectors.
• Read/Write Errors – Attributes such as smart.attributes.read_error_rate or smart.nvme_attributes.error_log_entries capture error frequencies.
• Power‑On Hours – smart.attributes.power_on_hours helps correlate wear with device age.

Monitoring these metrics over time allows administrators to spot gradual degradation before it manifests as data loss.

Querying Metrics on Demand

The pminfo command can retrieve the latest value of any metric. For example, to display the current temperature of all detected drives:

pminfo -ft smart.attributes.temperature_celsius.value
pminfo -ft smart.nvme_attributes.temperature_sensor_one

The -f flag formats the output as plain text, and -t adds a timestamp. To watch a metric update in real time, use the pmrep utility with a reporting interval. The following command prints temperature values every five seconds until interrupted:

pmrep -t 5s smart.nvme_attributes.temperature_sensor_one smart.attributes.temperature_celsius.value

Terminate the live view with Ctrl+C. Because pmrep reads from the PCP archive, the same command can be replayed later with a different time window to analyze historic data.

Integrating PCP SMART Data with Grafana

Grafana can visualize PCP metrics through the official PCP data source plugin. The integration steps are:

1. Install the Grafana PCP plugin on the Grafana server (refer to the plugin documentation for the exact package name).
2. Configure the plugin to connect to the local PCP collector by setting the address to localhost:44321 (the default PCP port).
3. Create a new dashboard and add panels that query the desired SMART metrics, for example:
   • Query: smart.attributes.temperature_celsius.value
   • Query: smart.nvme_attributes.temperature_sensor_one
4. Set the panel’s time range to “last 30 days” or longer to view trends.

Grafana’s alerting engine can also be configured to trigger notifications when a metric exceeds a threshold (e.g., temperature > 70 °C). Alerts rely on the same PCP data, ensuring that notifications are based on the continuous monitoring stream rather than an ad‑hoc snapshot.

Trade‑offs and Operational Considerations

Deploying continuous SMART monitoring introduces a few practical considerations:

• Resource Overhead – The SMART PMDA polls devices at a configurable interval (default is typically one minute). On systems with many drives, the cumulative I/O load is modest but should be verified on low‑power appliances.
• Data Retention – PCP archives metrics in a circular buffer. Administrators must size the archive to retain enough history for meaningful trend analysis (e.g., several months). The archive size is controlled in /etc/pcp/pcp.conf via the archive_size parameter.
• Device Compatibility – Not all drives expose the same SMART attribute set. The PMDA gracefully skips missing attributes, but dashboards should handle absent metrics to avoid false alerts.
• Security Context – Access to SMART data requires read permissions on the block device. The PMDA runs as the pcp user, which is granted the necessary group membership during package installation. Review the user’s privileges if the system enforces strict SELinux policies.
• Failure Detection vs. Prediction – SMART provides early warning signs but cannot guarantee failure prediction. Correlating temperature spikes with workload patterns and maintaining regular backups remain essential components of a robust storage strategy.

By balancing these factors, administrators can leverage PCP’s continuous SMART collection to move from reactive troubleshooting to proactive drive health management.

Source: fedoramagazine.org