Fedora Linux 45 Release Party: What the Event Signals for Deployment Planning

By the end of this article, you will understand the structure and technical choices behind the Fedora Linux 45 Global Virtual Release Party, what the current release pipeline means for upgrade planning, and why the event's infrastructure decisions matter for anyone who relies on Fedora in production or development environments.

The Release Pipeline and Its Practical Implications

Fedora Linux 44 is currently available, and Fedora Linux 45 is in its final polishing phase. Developers, packagers, and quality assurance engineers are actively working on the remaining details of the next release. The Global Virtual Release Party is scheduled for Friday, October 30, 2026, positioned to occur just after the final release ships. This timing is deliberate: the event is not a preview or a beta announcement, but a post-release celebration that coincides with the moment the new version becomes the current stable target.

For system administrators and developers who run Fedora in production or as a development baseline, this window between the availability of Fedora 44 and the imminent release of Fedora 45 is a practical decision point. Any infrastructure currently pinned to Fedora 44 will need an upgrade plan that accounts for the changes arriving in 45. The release party itself is not a substitute for reading the release announcement or testing in a staging environment, but it does provide a structured opportunity to hear directly from the project leadership about what changed and why. The event schedule includes updates from the Fedora Project Leader and behind-the-scenes looks at new features, which means the technical rationale for packaging decisions, feature additions, and deprecations will be presented in a format that is more accessible than reading through individual commit logs or mailing list threads.

The event is structured as a half-day programme combining live sessions with recorded deep-dives and community socialization. The recorded deep-dives are the most practically relevant component for administrators who cannot attend in real time or who need to reference specific technical details later. Because these recordings persist beyond the event itself, they function as a permanent knowledge artifact that can be revisited when planning an upgrade or troubleshooting a post-upgrade issue.

Element and Matrix as Community Event Infrastructure

The virtual venue for the release party is Element, built on the Matrix protocol. The Fedora project has continued to use this platform for its Global Virtual Release Parties, and the announcement explicitly acknowledges Element and Matrix.org for providing the tools that bring the global community together. This is a notable infrastructure choice when examined from a technical standpoint.

Matrix is a federated real-time communication protocol. Unlike proprietary video conferencing platforms, it does not lock participants into a single vendor's ecosystem or require a closed client application. Any Matrix-compatible client can connect to the event, which lowers the barrier to participation for users who prefer specific clients or who operate in environments where installing a particular application is restricted. The federation model also means that the event is not dependent on a single server instance being available; the protocol's design supports distributed hosting, which aligns with the decentralized values the Fedora project has historically emphasised in its infrastructure choices.

For administrators who are themselves evaluating Matrix for internal communications, the fact that a major open-source project uses it as the backbone for a global community event is a data point about the protocol's suitability for large-scale, time-sensitive use. The event is free and open to everyone, but registration is required to access the virtual venue. This registration gate serves a practical purpose: it allows the organisers to manage the scale of simultaneous participants and to distribute access credentials to the Matrix space in a controlled manner, rather than leaving the room open to unbounded join traffic that could degrade the experience for registered attendees.

What Changes in Practice

The release party does not change the technical content of Fedora 45 itself. No features are added, removed, or modified by virtue of the event taking place. What it changes is the accessibility of the information surrounding the release. The combination of a live leadership update and recorded technical deep-dives creates a lower-friction path to understanding what has changed in the distribution compared to the alternative of assembling that understanding from disparate sources such as release notes, package changelogs, and community forum discussions.

For teams that standardise on Fedora as a base image or deployment target, the event serves as a single point of reference for the changes that will affect their next upgrade cycle. The behind-the-scenes look at new features is particularly relevant for power users who need to understand not just what changed, but the reasoning behind packaging decisions, library version bumps, and architectural shifts that may not be immediately obvious from a changelog entry. The Fedora Project Leader's update provides context that connects individual package changes to broader project direction, which is information that is rarely captured in any other single artefact.

The event's format also reflects a broader pattern in how open-source projects manage the transition between development and release. The months of testing and collaboration that precede a release are not visible to end users until the release announcement appears. The release party partially closes that gap by making the process itself a subject of public discussion. For administrators who need to justify upgrade timing to stakeholders or who need to communicate changes to their teams, the recorded sessions provide citable material that explains the technical rationale for the new release in terms that can be relayed without requiring the audience to have deep familiarity with the Fedora packaging infrastructure.

Registration for the event is handled through Matrix, and the project has explicitly invited attendees to share the link with colleagues. The half-day duration means the commitment is modest relative to full-day technical conferences, which makes it more feasible for team members to attend without requiring extended time allocation. The recorded deep-dives ensure that the value of the event is not lost to those who could not attend live, which is significant for a global community spanning multiple time zones.

Source: fedoramagazine.org

Deploying Navidrome with Podman on Fedora – A Step‑by‑Step Guide

By the end of this article the reader will be able to install, configure, and run the Navidrome music server on a Fedora system using Podman, with SELinux contexts correctly applied and the service managed through podman‑compose.

Understanding Navidrome and Its Container Model

Navidrome is an open‑source music‑streaming server that serves a personal audio collection over HTTP. It is distributed as a set of multi‑architecture container images that include all runtime dependencies, eliminating the need for a host‑level package manager. The images are published under the deluan/navidrome repository and support the common architectures linux/amd64, linux/arm64, linux/arm/v6, and linux/arm/v7, making the same deployment process applicable to x86 servers as well as ARM‑based devices such as Raspberry Pi.

Podman is a daemonless container engine that implements the OCI container runtime specifications. It offers Docker‑compatible command‑line syntax while providing rootless execution and tighter integration with SELinux on Fedora. Because Podman does not require a central daemon, containers can be launched directly from a user session, and the podman unshare utility can be used to perform file‑ownership changes inside the user namespace, preserving the principle of least privilege.

Preparing the Host Environment

The first step is to ensure that the host system has the required tools installed. Fedora includes Podman in its default repositories, and the optional podman-compose package provides a Docker‑Compose‑compatible front‑end.

Install the necessary packages with the following command, which adds the Podman binaries and the compose helper:

sudo dnf install -y podman podman-compose

This command installs the podman engine, the podman-compose script, and any required SELinux policy modules. The installation can be reversed by removing the packages with sudo dnf remove podman podman-compose.

Creating the Directory Structure

Navidrome expects two persistent volumes: one for its internal database and configuration (/data) and one for the music collection (/music). Create a dedicated directory hierarchy in the user’s home directory to hold these files.

mkdir -p /home/nico/navidrome/{Data,Music}

The command creates Data and Music sub‑directories under /home/nico/navidrome. Ownership and SELinux labeling will be addressed in the next steps.

Applying SELinux Contexts

When SELinux is enforcing (the default on Fedora), container processes are confined by the container_file_t type. To allow the Navidrome container to read and write its data directories, the host directories must be labeled accordingly.

Add the SELinux file context for each directory and its contents:

sudo semanage fcontext -a -t container_file_t '/home/nico/navidrome/Data(/.*)?'
sudo semanage fcontext -a -t container_file_t '/home/nico/navidrome/Music(/.*)?'

These commands register a persistent mapping that tells SELinux to treat any file under the specified paths as container_file_t. Apply the mapping immediately with:

sudo restorecon -R /home/nico/navidrome/Data
sudo restorecon -R /home/nico/navidrome/Music

If later adjustments are required, the semanage fcontext -d command can delete the rule, and restorecon can be re‑run to revert the labeling.

Setting Correct Ownership

Navidrome runs inside the container as a non‑root user with UID 1000 and GID 1000. To avoid permission errors, the host directories must be owned by the same identifiers. Because the host user may have a different UID, the podman unshare command performs the ownership change inside a user namespace, ensuring the container sees the correct ownership without requiring root privileges on the host filesystem.

podman unshare chown 1000:1000 /home/nico/navidrome/Data
podman unshare chown 1000:1000 /home/nico/navidrome/Music

These commands change the owner and group of the two directories to UID 1000/GID 1000. To revert, run the same commands with the original UID/GID values.

Defining the Container with podman‑compose

Using podman-compose simplifies multi‑container orchestration and mirrors the familiar Docker‑Compose workflow. Create a podman-compose.yml file in the same directory as the data volumes.

cat > podman-compose.yml <<'EOF'
version: "3"
services:
  navidrome:
    image: deluan/navidrome:latest
    user: 1000:1000
    ports:
      - "4533:4533"
    restart: unless-stopped
    environment:
      ND_SCANSCHEDULE: 1h
      ND_LOGLEVEL: info
      ND_SESSIONTIMEOUT: 24h
      ND_BASEURL: ""
    volumes:
      - "/home/nico/navidrome/Data:/data"
      - "/home/nico/navidrome/Music:/music:ro"
EOF

The file declares a single service named navidrome. Key elements:

• image: pulls the latest official Navidrome image from Docker Hub.
• user: runs the container with UID/GID 1000, matching the host directory ownership.
• ports: maps host port 4533 to the container’s HTTP port.
• restart: ensures the container restarts automatically unless stopped manually.
• environment: optional variables that control scan frequency, log level, session timeout, and base URL. The values shown are the defaults; they can be omitted or customized as needed.
• volumes: mounts the persistent data directory as read/write (/data) and the music collection as read‑only (/music:ro) to prevent accidental modification from within the container.

Launching the Service

Start the Navidrome container in detached mode with:

podman-compose up -d

Podman pulls the image if it is not already cached, creates the container, and starts it. The -d flag runs the container in the background. To stop and remove the service, use:

podman-compose down

The command stops the container and removes the associated pod and network resources, leaving the host‑side data directories untouched.

Alternative One‑Shot Run Command

For environments where a compose file is unnecessary, the same container can be launched directly with a single podman run invocation. This approach is useful for quick tests or when integrating Navidrome into an existing script.

podman run -d \
  --name navidrome \
  --restart=unless-stopped \
  --user $(id -u):$(id -g) \
  -v /home/nico/navidrome/Music:/music:ro \
  -v /home/nico/navidrome/Data:/data \
  -p 4533:4533 \
  -e ND_LOGLEVEL=info \
  deluan/navidrome:latest

Explanation of the flags:

• -d: run in detached mode.
• --name: assign a stable container name for later management.
• --restart=unless-stopped: replicate the compose restart policy.
• --user $(id -u):$(id -g): dynamically set the UID/GID to match the invoking user, ensuring correct file permissions.
• -v: bind‑mount the host directories; the music mount is read‑only.
• -p: expose port 4533 on the host.
• -e: set environment variables; only ND_LOGLEVEL is shown as an example.

To stop this container, execute podman stop navidrome followed by podman rm navidrome. The data stored in the host directories remains intact.

Verification and Routine Operations

After the container is running, verify that Navidrome is reachable by requesting the HTTP endpoint:

curl -s http://localhost:4533/ | grep -i navidrome

A successful response contains the Navidrome HTML title, confirming that the service is listening on the expected port. For a more detailed health check, inspect the container logs:

podman logs navidrome

Typical log entries include the startup banner, the configured scan schedule, and any errors related to accessing the music directory. Because the music mount is read‑only, permission‑denied messages indicate an SELinux labeling issue; re‑run restorecon if necessary.

To trigger a manual library rescan without restarting the container, set the ND_SCANSCHEDULE environment variable to 0 and send a SIGHUP to the process. This can be done via podman exec:

podman exec navidrome pkill -HUP navidrome

The command sends a hang‑up signal to the Navidrome process, causing it to re‑read the music directory. The operation does not modify container configuration and can be reversed by sending a regular SIGTERM to stop the container if needed.

Trade‑offs and Operational Considerations

Deploying Navidrome with Podman on Fedora offers several advantages:

• Rootless operation: By running containers as an unprivileged user, the attack surface is reduced compared with traditional Docker daemons.
• SELinux integration: Proper labeling ensures that the container cannot escape its confined file‑system view, complying with Fedora’s default security posture.
• Architecture portability: The same compose file works on both x86_64 and ARM platforms, simplifying management of heterogeneous hardware.

However, there are practical trade‑offs to consider:

• Performance of bind mounts: Accessing a large music library over a bind mount may incur additional overhead compared with using a dedicated volume driver. Monitoring I/O latency on the host can reveal bottlenecks.
• Backup strategy: The /data directory contains the Navidrome SQLite database and configuration files. Regular backups of /home/nico/navidrome/Data are required to protect against data loss, as container restarts do not affect the host‑side files.
• Network exposure: Exposing port 4533 directly to the host makes the service reachable on any network interface. In production environments, consider placing a reverse proxy (e.g., Nginx) in front of Navidrome to enforce TLS and add authentication layers.
• Resource limits: Podman does not impose default CPU or memory limits. For high‑traffic deployments, define explicit --cpus and --memory constraints in the compose file to prevent a single container from exhausting host resources.

By following the steps outlined above, system administrators can maintain a reproducible, SELinux‑compliant Navidrome deployment that remains functional across hardware revisions and Fedora updates for the foreseeable future.

Source: fedoramagazine.org

Fedora 45 Brings Stratis Storage Into the Anaconda Installer

By the end of this article, you will understand how Fedora 45's Anaconda installer incorporates Stratis storage, what the two-layer pool-and-filesystem model means in practice, which features are available at install time, and which must be configured afterward.

Stratis as an integration layer

Stratis is not a new storage technology in the sense of introducing novel on-disk formats or proprietary abstractions. It builds on device mapper, LUKS, and XFS — components that have been part of the Linux storage stack for years — and wraps them in a unified management interface. The value proposition is not that it can do something none of those tools could do individually, but that it collapses the multi-step configuration an administrator previously had to perform by hand into a single logical operation. The complexity of coordinating encryption, provisioning, and filesystem creation across separate tools is hidden behind a simpler model.

That model is deliberately minimal. There are two structural layers: pools and filesystems. A pool is an abstract container that sits on top of one or more block devices — whole disks, partitions, RAID arrays. It is the unit at which encryption and over-provisioning are configured. Filesystems are created on top of a pool and serve as the actual mount points: root, home, or any other logical volume an administrator needs. This two-layer model is intentionally simpler than LVM's triple indirection (physical volume, volume group, logical volume), which is part of why Stratis has been gaining traction in desktop and small-server deployments where the full LVM workflow is overkill.

Beyond the basic structure, Stratis supports snapshots, caching, and — for encrypted pools — multiple unlocking methods including TPM and Clevis/Tang. These are not new capabilities either; they are features that already existed in the underlying technologies but required separate tooling and manual coordination to combine into a working configuration.

What the Fedora 45 installer actually offers

The practical change in Fedora 45 is that Stratis is now reachable during installation through the Anaconda installer. However, the path to it is not the most direct one. The new web-based user interface for Anaconda does not currently allow the user to select which storage technology underlies the automated or guided partitioning options. The resulting layout depends on the Fedora variant being installed, and Stratis is not one of the choices presented in that automated flow.

To get Stratis during installation, the user must select the "If none of the options above apply…" option on the Installation Destination step, which opens the Cockpit storage module integrated into the installer. Cockpit supports a wide variety of storage configurations, and Stratis is among them. From there, the administrator follows a manual partitioning workflow: first creating the partitions required for booting (/boot and either /boot/efi or biosboot, depending on the system's firmware configuration), then creating a Stratis pool from the Cockpit interface. After the pool exists, filesystems for / and /home are added to it.

This is a meaningful distinction. Stratis is not being pushed as the default or even a first-class guided option alongside LVM or Btrfs in the automated path. It is available, but it requires the administrator to opt into manual partitioning and navigate the Cockpit module. For a desktop user who wants the simplest possible install, this is a non-starter. For an administrator who has decided they want Stratis and is willing to take a few extra steps, it eliminates the need to wait for the base install to complete before setting up storage. The installer now handles the structural setup in one pass rather than requiring a separate post-install configuration session.

Over-provisioning and the trade-off it introduces

The feature that makes Stratis most relevant to administrators is over-provisioning. When enabled at the pool level, it allows filesystems created on that pool to be allocated more space than the pool physically contains. The mechanism is analogous to thin provisioning in LVM and to the overcommit model in Btrfs: the system does not enforce a hard boundary at allocation time, and instead relies on the administrator to monitor actual usage against real capacity.

The practical benefit is straightforward. In a traditional partitioned or LVM setup, if /home fills up while / still has free space, the system may become unresponsive because root cannot write to its own directories. With over-provisioning, that scenario is less likely to occur in a sudden, catastrophic form — space can effectively flow between filesystems as needed. It also provides greater flexibility when using snapshots, since a snapshot does not immediately consume the full size of the filesystem it references. An administrator who takes frequent snapshots of a large volume is no longer forced to reserve the full size of each snapshot up front.

The risk is the mirror image of the benefit. An administrator who allocates 2 TB across two filesystems on a 1 TB pool is not actually managing 2 TB of storage. If both filesystems grow toward their allocated sizes simultaneously, the pool will exhaust its real capacity, and the consequences are the same as running out of disk space on a traditional system: writes fail, services may crash, and recovery requires freeing space or expanding the pool. Stratis does not prevent this; it defers the failure to a point where the administrator must have been monitoring aggregate usage. For a single-user desktop this is a manageable risk. For a multi-tenant server where multiple workloads share a pool, it demands a monitoring strategy that accounts for the total allocation exceeding physical capacity. Both over-provisioning and encryption can be toggled on or off after installation, so the decision made at install time is not permanent.

What is deferred to post-install

Not all Stratis features are available through the Anaconda installer. Caching is not currently supported during installation, and neither is encryption without a passphrase. Both can be enabled after the base installation is complete, which means an administrator who wants passphraseless encryption via TPM or Clevis/Tang, or who wants a read cache on a pool, will need to configure those after booting into the installed system. This is a reasonable compromise: the installer handles the structural setup — pool creation, filesystem creation, basic encryption with a passphrase — and the more advanced or niche configurations are left to the post-install environment where the full stratis command-line tool is available.Source: fedoramagazine.org

Fedora 45 Beta Introduces kmscon, Enforced RPM Signatures, and Updated Stacks

By the end of this article the reader will understand the technical implications of Fedora 45 Beta’s shift to a userspace console, the enforcement of RPM signature verification, and the impact of updated desktop stacks and installer enhancements on daily administration tasks.

Desktop Stack Updates and Kernel Refresh

Fedora 45 Beta ships with GNOME 51 and KDE Plasma 6.7, representing the latest releases of the two major desktop environments supported by the distribution. Both environments benefit from upstream improvements in performance, Wayland integration, and UI polish, but the practical effect for administrators is a need to verify compatibility of any custom extensions, themes, or third‑party applications that interact with the desktop layer. The kernel upgrade to version 7.2 brings the usual set of new hardware drivers, scheduler refinements, and security mitigations. While the kernel version alone does not dictate a change in workflow, the presence of newer driver stacks may require updates to firmware packages or adjustments to boot parameters for legacy hardware.

Transition from In‑Kernel fbcon to kmscon

One of the most consequential changes in Fedora 45 Beta is the replacement of the traditional in‑kernel framebuffer console (fbcon) with kmscon, a userspace console and terminal emulator. Unlike fbcon, which renders text directly through a simple framebuffer driver, kmscon leverages Kernel Mode Setting (KMS) and the Direct Rendering Manager (DRM) subsystem to produce output. This architectural shift yields several technical advantages:

Improved Font Rendering and Unicode Support

kmscon’s reliance on KMS/DRM allows it to use modern font rasterizers and full Unicode handling. Administrators who routinely work with multilingual logs or need high‑resolution console output will notice sharper glyphs and correct rendering of complex scripts without the workarounds required under fbcon.

Consistent Graphics Path Across Sessions

Because kmscon operates in userspace, it shares the same graphics stack as graphical sessions. This uniformity simplifies troubleshooting of display‑related issues that span both console and X/Wayland environments. For example, a misconfiguration in DRM that would previously affect only graphical sessions now manifests consistently in the console, making root cause analysis more straightforward.

Impact on Login Prompt and agetty

The traditional agetty login prompt, which relied on the kernel VT, is replaced by kmscon’s integrated terminal emulator. This change does not alter the authentication flow but does affect the underlying process handling the login prompt. System administrators should verify that any custom agetty configurations or PAM modules continue to function under the new console manager. Existing systemd service files that invoke agetty remain valid, as kmscon provides a compatible interface, but logs should be monitored during the beta period for any unexpected failures.

Enforced RPM Package Signature Verification

Fedora 45 Beta enables RPM signature verification by default, rejecting any unsigned packages during installation or upgrade. This policy hardens the package management pipeline against supply‑chain tampering by ensuring that every RPM present in the repositories carries a cryptographic signature that matches the trusted keyring.

For administrators, the immediate effect is that any locally built or third‑party RPMs lacking a signature will be blocked unless the verification step is explicitly disabled. This encourages the adoption of signing practices for internal build pipelines. When integrating custom repositories, maintainers must import the appropriate GPG keys into the system’s RPM keyring to avoid installation errors. The ability to disable verification remains, but it should be reserved for controlled testing environments, as doing so reintroduces the risk of unsigned code execution.

Installer Enhancements: Stratis Support and Image‑Builder Integration

Anaconda, Fedora’s installer, now includes native support for Stratis partitioning. Stratis provides a combined volume management and filesystem solution that abstracts block device handling while offering thin provisioning and snapshot capabilities. Administrators planning deployments that require flexible storage layouts can now select Stratis directly during the installation workflow, eliminating the need for post‑install manual configuration.

The ISO creation process has been updated to use image‑builder. This tool standardizes the generation of bootable images, ensuring that the resulting ISOs contain a reproducible set of packages and metadata. For developers maintaining custom spin images, the shift to image‑builder simplifies the build pipeline and improves traceability of included components.

DNF5 Vendor Switching Behavior

DNF5, the next‑generation package manager, will no longer automatically switch installed packages between vendors during upgrades. Previously, DNF could replace a package from one vendor with an equivalent from another if the latter had a higher version, a behavior that sometimes led to unexpected changes in the provenance of critical software. By disabling this automatic vendor swapping, Fedora 45 Beta ensures that the origin of installed packages remains consistent across upgrade cycles, aiding compliance tracking and reducing the surface for inadvertent supply‑chain alterations.

Practical Considerations for System Administrators

The cumulative effect of these changes requires a modest adjustment in routine administration:

• Validate that any custom console scripts or agetty modifications operate under kmscon. Review system logs after the first boot to confirm that the login prompt appears as expected.
• Audit internal RPM build processes to incorporate GPG signing. Update CI pipelines to sign artifacts before pushing them to internal repositories.
• When planning new deployments, evaluate Stratis as the default storage backend if its feature set aligns with workload requirements. Familiarity with the Stratis CLI will be necessary for post‑install management.
• Review Anaconda kickstart files for any references to legacy partitioning schemes that may need replacement with Stratis directives.
• Monitor DNF5 upgrade logs to ensure that vendor stability is maintained, particularly in environments with mixed‑vendor repositories.

Impact on Developers and Power Users

Developers targeting Fedora 45 will encounter the latest GNOME and KDE releases, which may introduce API deprecations or new extension points. The shift to kmscon also means that terminal‑based tools that rely on precise console dimensions or font metrics may observe different behavior, prompting updates to UI rendering code that assumes the older fbcon characteristics.

Power users who customize their console experience will need to adapt configuration files that previously interacted with fbcon. Since kmscon runs in userspace, it supports configuration through standard XDG directories, offering a more flexible mechanism for theme and font selection. This aligns the console configuration experience with that of graphical terminals, simplifying the overall customization workflow.

Next Steps for Early Adopters

Administrators interested in evaluating Fedora 45 Beta should download the ISO from the official Fedora download site and perform a test installation on non‑production hardware. During the testing phase, focus on verifying console functionality, RPM signature enforcement, and storage provisioning with Stratis. Document any deviations from expected behavior and report them to the Fedora development mailing lists to aid in the final stabilization of the release.

Source: linux-magazine.com

Streamlining Fedora Event Recordings: From Raw Footage to Multi‑Platform Publication

By the end of this article readers will understand how the Fedora community transformed raw livestream recordings of the 2025 and 2026 Flock To Fedora events into polished videos for YouTube and PeerTube, the tooling choices that enabled the workflow, and the implications for future community‑driven media publishing pipelines.

Context and Motivation

The Flock To Fedora conferences generate several days of continuous livestream content across multiple thematic tracks. Historically, the raw footage resides in a shared storage location, but the path structures and naming conventions are not aligned with downstream publishing needs. For the 2025 recordings, the delay in uploading highlighted the necessity of a reproducible, well‑documented process that could keep pace with community expectations for timely access.

The Fedora infrastructure team therefore revisited an earlier tooling set created by Adrian Edwards, which already handled basic slicing, thumbnail generation, metadata attachment, and upload to the Fedora YouTube channel. The goal was to adapt this foundation for the 2025 and 2026 sessions, introduce a phased release strategy that leverages PeerTube as an intermediate platform, and resolve practical obstacles such as inconsistent file organization and bandwidth constraints.

Key Components of the Publishing Pipeline

Footage Organization – The 2025 event spanned four days (04 June 2025 – 07 June 2025) and four distinct tracks (Plenary, Topaz, Opal, Quartz). The raw video files were stored in a loosely structured hierarchy, requiring manual reconciliation. Shounak Dey contributed a spreadsheet that mapped each footage file to its corresponding session, providing a single source of truth for subsequent processing steps.

Timestamp Annotation – Accurate session boundaries are essential for slicing. Initial attempts to use SponsorBlock for automated timestamp extraction proved inefficient, leading the team to revert to manual annotation with VLC Media Player. This hands‑on approach, while labor‑intensive, ensured precise start and end markers for each segment.

Video Slicing – The LosslessCut application served as the primary tool for extracting individual sessions from the larger footage files. LosslessCut operates on a lossless basis, preserving the original video quality while allowing rapid segment selection based on the manually curated timestamps.

Automation Scripts – Adrian Edwards’ Python scripts automate repetitive tasks such as batch slicing, thumbnail creation, and metadata insertion. These scripts were integrated into the workflow after the manual slicing step, reducing the risk of human error and accelerating the preparation of upload‑ready assets.

Thumbnail Templates – Visual consistency across published videos is maintained through predefined thumbnail templates stored in a separate repository. Access to these assets required additional coordination, illustrating the importance of co‑locating ancillary resources with the main processing scripts.

Upload Strategy – The team adopted a phased release model: sessions are first published on PeerTube, followed by YouTube. This approach serves two purposes. First, it leverages PeerTube’s federated nature to reach audiences interested in open‑source video platforms. Second, the staggered rollout maintains audience engagement over an extended period, allowing the community to monitor viewership metrics and adjust promotion tactics before the final YouTube release.

Technical Implications for System Administrators

The described workflow underscores several considerations that administrators overseeing community media pipelines should evaluate.

File System Layout and Naming Conventions

Inconsistent directory structures can dramatically increase manual effort during the preprocessing phase. Implementing a standardized naming scheme—such as {year}_{track}_{date}_{session_id}.mp4—at the point of capture would eliminate the need for extensive spreadsheet mapping. Administrators can enforce such conventions through automated ingestion scripts that rename files as they are uploaded to the central storage.

Bandwidth Management

The team noted network bandwidth as a limiting factor during the processing stage. Large raw footage files, especially when dealing with multiple days of high‑definition streams, can saturate shared links. Administrators should consider scheduling intensive processing tasks during off‑peak windows or provisioning dedicated transfer paths (e.g., a separate VLAN or a high‑throughput storage appliance) to isolate video workflow traffic from regular infrastructure usage.

Tool Integration and Dependency Isolation

The pipeline combines GUI‑based tools (LosslessCut, VLC) with command‑line scripts (Python automation). Maintaining a reproducible environment for the scripts is critical. While the source does not detail containerization, administrators can achieve isolation by using virtual environments or lightweight containers that bundle the required Python dependencies, ensuring that updates to system libraries do not break the automation.

Metadata and Thumbnail Consistency

Metadata insertion and thumbnail generation are handled by the same Python scripts that perform slicing. Centralizing these assets in a version‑controlled repository simplifies updates and provides auditability. Administrators should enforce repository access controls and implement CI pipelines that validate the presence of required fields (title, description, tags) before allowing a commit, thereby preventing incomplete uploads.

Phased Publication Workflow

Releasing videos first on PeerTube and later on YouTube introduces a synchronization challenge: ensuring that metadata, thumbnails, and descriptions remain consistent across platforms. Automation scripts can be extended to generate platform‑specific payloads, but administrators must also monitor API rate limits and authentication scopes for both services. Proper credential management—preferably using OAuth tokens stored in a secure vault—prevents accidental exposure of privileged access.

Collaboration and Documentation

The process benefited from clear division of labor: one contributor focused on timestamp annotation while another handled slicing. Maintaining up‑to‑date documentation, especially regarding path locations and repository links, is essential for onboarding new volunteers. Administrators can host the documentation in a shared wiki with edit history, ensuring that changes to the workflow are tracked and reversible.

Impact on Fedora Community Practices

The successful publication of the 2025 and 2026 Flock To Fedora recordings demonstrates a scalable model for community‑driven media distribution. By leveraging open‑source tools and a modest amount of custom scripting, the Fedora infrastructure team avoided the need for proprietary video processing suites, aligning the workflow with the broader ethos of the distribution.

The phased release strategy also establishes a template for future events. Communities can adopt PeerTube as an initial distribution channel to foster engagement with federated platforms, then transition to mainstream services like YouTube for broader reach. This dual‑platform approach mitigates reliance on a single service and provides redundancy in case of platform‑specific outages.

From an operational perspective, the experience highlights the value of early planning for media assets: consistent file naming, pre‑allocation of storage, and bandwidth provisioning can reduce post‑event workload dramatically. Moreover, the reuse of existing scripts illustrates how incremental improvements to a shared codebase can yield substantial time savings across multiple events.

Overall, the Fedora team’s refinement of its video publishing pipeline offers a concrete example of how open‑source communities can manage large‑scale media workflows without incurring significant overhead. System administrators and developers can adopt the documented practices—standardized naming, automated slicing, centralized metadata, and phased releases—to streamline their own event recording pipelines, ensuring that valuable community content reaches audiences promptly and reliably.

Source: fedoramagazine.org

Fedora Outperforms Windows 11 in Real‑World Laptop Benchmarks

By the end of this article readers will understand how a controlled comparison between Fedora and Windows 11 on identical Dell XPS 13 hardware revealed consistent performance advantages for Fedora across a range of everyday and creative workloads, and what those results imply for system administrators, developers, and power users when choosing an operating system for productivity‑focused laptops.

Test Methodology and Environment

PhoneBuff, a firm known for robotic, repeatable hardware testing, selected two Dell XPS 13 laptops equipped with identical Intel Core i5‑3200 U processors and 8 GB of RAM. One machine ran Windows 11, the other Fedora Linux. All variables unrelated to the operating system were standardized: screen brightness set to 200 nits, Wi‑Fi distance equal for both devices, and ambient temperature controlled. Each workload was executed three to five times, with the median duration recorded to smooth out outliers.

The testing framework employed a “clanker”—a robotic mouse and keyboard—to simulate real user interaction, ensuring consistent input timing across runs. This approach eliminates human timing variance and provides a repeatable baseline for comparing raw OS performance.

Boot and Restart Performance

Cold boot times from a full shutdown were effectively identical, with Windows 11 measuring 23 seconds and Fedora 24 seconds. The margin is within the test’s natural variance and therefore not a decisive factor. However, restart performance diverged sharply. Fedora completed a median restart in 27 seconds, while Windows 11 required 61 seconds. Windows 11’s five measured restarts ranged from 46 to 68 seconds, whereas Fedora’s spanned 23 to 34 seconds, indicating a more predictable and faster restart cycle on the Linux distribution.

File Operations: Unzipping Large Archives

The most pronounced disparity emerged in file extraction. Both systems were tasked with unzipping a 6 GB archive. Fedora’s native archive utility completed the operation in 12 seconds. In contrast, Windows Explorer required 57 seconds, and even after installing the third‑party 7‑Zip utility, the time only reduced to 17.4 seconds. This result underscores the efficiency of Fedora’s default compression tools and the impact of filesystem handling differences between the two operating systems.

Development Workflows: VS Code Project Build

A realistic development scenario was simulated by loading an open‑source whiteboard project in Visual Studio Code, scanning for errors, compiling, and executing approximately 1,900 tests. Fedora completed the entire pipeline in 2 minutes 20.5 seconds, whereas Windows 11 took 3 minutes 41.99 seconds. The roughly 45 percent reduction in total build time on Fedora suggests lower overhead in the toolchain, faster I/O handling, and potentially more aggressive caching strategies in the Linux kernel.

Creative Application Benchmarks

Two professional‑grade creative workloads were measured. DaVinci Resolve imported two video clips, applied color grading to one, stabilized the other, and exported the final product. Fedora completed the process in 2 minutes 10.9 seconds; Windows 11 required 2 minutes 49.9 seconds. Similarly, a GIMP session involving a 4K image—executing smudge, heal, and object removal tools—finished in 53.3 seconds on Fedora versus 60.7 seconds on Windows 11. These results indicate that Fedora’s graphics stack, including drivers and compositor interactions, can deliver measurable gains in media processing tasks.

Everyday Application Performance

For routine productivity software, the two operating systems produced mostly comparable results. The article notes that Chrome performance on a locally hosted environment resulted in a tie, though specific timing data is not provided. This parity suggests that for web browsing and similar low‑intensity tasks, the choice between Fedora and Windows 11 may be driven more by ecosystem considerations than raw speed.

Technical Factors Behind Fedora’s Edge

Several underlying technical aspects likely contributed to Fedora’s superior performance across the measured workloads:

• Kernel I/O Scheduling: The Linux kernel’s default I/O scheduler, often set to deadline or bfq on Fedora, can provide more deterministic disk access patterns compared to Windows’ scheduler, benefiting large file operations such as archive extraction.
• Filesystem Differences: Fedora typically ships with ext4 or XFS, both of which have mature journaling and allocation strategies. Windows 11 uses NTFS, which may incur additional metadata handling overhead, especially noticeable in bulk file operations.
• Process Scheduling and Context Switching: Linux’s CFS (Completely Fair Scheduler) is designed for low latency and efficient CPU sharing among processes, which can reduce the cumulative cost of repeated short tasks like compilation steps.
• Graphics Stack Optimization: Fedora’s integration of Mesa, open‑source drivers, and Wayland (or X11 with optimized drivers) can lead to lower rendering latency for GPU‑accelerated applications, as reflected in the DaVinci Resolve and GIMP benchmarks.
• Toolchain Efficiency: The default GNU toolchain and libraries on Fedora are often compiled with performance‑focused flags, and the distribution’s package manager ensures that binaries are up‑to‑date, potentially offering faster execution for development tools.

Implications for System Administrators and Power Users

The data presented by PhoneBuff carries practical weight for administrators responsible for provisioning laptops to developers, designers, or other knowledge workers. When the primary use case involves frequent restarts, large file handling, or media processing, Fedora demonstrates a clear advantage that can translate into measurable productivity gains.

For organizations standardizing on a Linux desktop, the Fedora benchmark validates its suitability as a performance‑oriented baseline. Administrators can leverage Fedora’s predictable restart times to reduce downtime during updates or policy changes. The faster archive extraction also benefits automated deployment pipelines that rely on unpacking large codebases or data sets.

Developers may find the reduced build times especially compelling. A 45 percent improvement in a typical CI/CD step suggests that local development cycles can be shortened, allowing for more rapid iteration. When combined with Fedora’s up‑to‑date compiler and library stack, the environment can serve as a high‑performance platform for both native and cross‑compiled workloads.

Creative professionals using DaVinci Resolve, GIMP, or similar tools can expect shorter render and export times, which directly impacts project turnaround. While Windows 11 remains a dominant platform for many commercial creative suites, the benchmark indicates that open‑source alternatives on Fedora can compete effectively, especially when paired with compatible hardware drivers.

Finally, the parity observed in everyday applications like Chrome suggests that switching to Fedora does not compromise the user experience for standard tasks. Administrators can therefore consider Fedora as a viable default desktop OS without risking regressions in typical productivity workflows.

Operational Takeaways

The PhoneBuff comparison reinforces several actionable points for those managing Linux deployments:

• Prioritize a Linux distribution that ships with a recent kernel and up‑to‑date graphics drivers to maximize performance gains in media‑intensive workloads.
• Leverage Fedora’s default filesystem choices for environments where large archive handling is frequent, as the observed extraction speed advantage can reduce batch processing times.
• When configuring CI pipelines on developer laptops, consider Fedora’s faster restart and build characteristics to improve overall development velocity.
• Maintain consistent hardware configurations across test groups to ensure that observed performance differences are attributable to the operating system rather than underlying components.

In summary, the controlled benchmarks demonstrate that Fedora consistently outperforms Windows 11 in several high‑impact scenarios on identical Dell XPS 13 hardware. System administrators and power users can use these findings to inform OS selection, optimize workflow efficiency, and justify the adoption of Fedora as a primary desktop platform for performance‑sensitive tasks.

Source: feed.itsfoss.com

Recovering from Btrfs Boot Failures Using GUI Tools on Fedora

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

Fedora Badges Service Rebuilt as a Modern SPA

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

Fedora 45 Test Days: Community‑Driven Validation of Core System Changes

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

Continuous SMART Monitoring with Performance Co‑Pilot on Fedora

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