11 Dec 2025
Fedora People
Peter Czanik: The syslog-ng Insider 2025-12: logrotation; release RPM; nightly RPM
11 Dec 2025 12:15pm GMT
10 Dec 2025
Fedora People
Fedora Infrastructure Status: matrix server upgrades
10 Dec 2025 12:30pm GMT
Ben Cotton: The do’s and don’ts of measuring contributions “outside of working hours”
LFX Insights is a handy platform from the Linux Foundation that provides a variety of data on open source projects. Among the statistics it reports is contributions outside of working hours. Some users reported errors with how this information is reported, which got me thinking about the value of this measure. The short version: there's very little value.
Why measure outside-of-working-hours contributions?
LFX Insights includes this measure as a signal of a project's sustainability. Projects that rely heavily on people making after hours contributions, the thinking goes, will have a harder time attracting and retaining contributors.
As a software consumer, you don't want your upstreams to suddenly disappear because that will present supply chain risks. It could mean vulnerabilities go unpatched. It could also mean that new features aren't added. Either way, this puts the onus on the project's users to carry the load.
As a project leader, you may be less concerned about whether or not a company downstream has to devote extra engineering time, but you probably do want your contributors to stick around anyway. Onboarding, mentoring, and growing contributors takes a lot of time and effort. You want to make sure people can stick around.
Why this measure fails
Despite the good intentions of measuring contributions outside working hours, the reality fails to deliver. There are some straightfoward reasons for this. Not everyone's working hours are the same. Not everyone's working hours are consistent. Some people use a different time zone on their computer. Not everyone's working days are the same. Holidays vary widely across countries and religions. People (hopefully) take time off.
Then there's the cultural mismatch. Linux Foundation projects are, to a first approximation, by companies for companies. The Linux Foundation is a 501(c)(6), not a charity, so it makes sense that it would view the world through a business lens. I don't fault them for that. LF project contributors are more likely to make contributions during the working day than contributors to a "hobbyist" project.
But that workday tendency doesn't necessarily mean people will stick around projects longer if the project is tied to their job. As the last few years have shown, tech sector layoffs can come for anyone at any time. If someone is only working on an open source project because it's part of their job, then when the job changes, they'll probably stop. People who work on an open source project for non-job reasons will likely stick around through job changes.
Thus one could argue that a project with a high degree of outside-working-hours contributions is more sustainable.
What to measure instead
If measuring contributions outside of working hours isn't helpful, what is? Focus on what you're worried about. Worried that everyone will disappear? Measure the activity over time. Worried that when a new vulnerability is discovered the lone maintainer will be backpacking through the Alps? Measure the spread of the contributions. Worried that the project doesn't have enough people to follow secure coding practices? Measure the security posture.
Of course, the best answer is to stop trying to measure sustainability and contribute to making the project more sustainable instead.
This post's featured photo by Joshua Olsen on Unsplash.
The post The do's and don'ts of measuring contributions "outside of working hours" appeared first on Duck Alignment Academy.
10 Dec 2025 12:00pm GMT
Fedora Magazine: Talk to your Fedora system with the linux-mcp-server!

Generative AI systems are changing the way people interact with computers. MCP (model context protocol) is a way that enables LLMs to run commands and use tools to enable live, conversational interaction with systems. Using the new linux-mcp-server, let's walk through how you can talk with your Fedora system for understanding your system and getting help troubleshooting it!
Introduction
Large language models (LLMs) can be an invaluable tool when investigating an issue on a Linux system. However, this can involve a lot of copy/pasting of information from the Linux terminal into a web based interface to an LLM model.
The model context protocol (MCP) acts as a bridge, enabling LLMs to interact with external tools and data sources. The linux-mcp-server utilizes this protocol to give LLMs the ability to interact with a Fedora Linux system. Instead of you manually copying and pasting terminal output, the linux-mcp-server enables the LLM to directly query system information and log entries.
By enabling an LLM direct access to system information and logs, it is transformed into an active part of the investigation process when troubleshooting an issue. It empowers an LLM to directly query the system state, allowing it to help identify performance bottlenecks, and identify important log entries that might be missed by a manual review.
What is the model context protocol (MCP)?
Anthropic introduced MCP in November 2024 as an open standard for LLM tool use. This provides a way for LLMs to interact with outside systems and data sources.
Prior to MCP, there wasn't as strong a standard and ecosystem for LLM systems to call tools. LLMs were thus frequently limited to have only the information contained in their training. They were isolated from the outside world. For example, if you asked an LLM "what is the weather going to be next week", the LLM would respond with a message indicating that it doesn't know what the weather will be, as it doesn't have access to that information. MCP helps solve this problem by enabling a standardized way for an LLM to access an outside data source, such as the weather forecast.
At a high level, users can use an AI agent application, such as Goose (open source), or Claude Desktop, and specify which MCP servers they would like to use. The AI agent application informs the LLM that there are tools available via these MCP servers that can be used to help answer the requests from the user. The LLM model can then decide when to invoke these tools.
MCP is an open standard. You have the flexibility to use MCP servers, such as linux-mcp-server, with either open source-licensed LLM models, or hosted proprietary LLM models.
What is the linux-mcp-server?
The linux-mcp-server is a project started by Red Hat's RHEL Engineering team. It provides a number of tools that enable an LLM to query information from a Linux system, such as system info, service information and logs, process information, journald and other logs, network information, and storage and disk information. For a full list of the tools provided, refer to the project's Github page.
These tools, provided by linux-mcp-server, are focused on providing the LLM access to read-only information. In the future, we'll be exploring expanding past these read-only use cases.
The linux-mcp-server can be used to interact with the local Fedora Linux system that it is running on. It can also be used to interact with remote Fedora Linux systems over SSH. For example, if you have SSH key authentication setup with the remote systems, you could make a request to your AI agent application such as "Determine the current memory usage on the fedora1.example.com, fedora2.example.com, and fedora3.example.com servers".
Prerequisites
The main components needed are an AI agent application, access to LLM model inference, and the linux-mcp-server.
There are a number of options for the AI agent application, both open source and proprietary. An example of an open source AI agent is Goose, which provides an RPM that can be installed on Fedora.
There are several LLM model inference options, ranging from locally hosted open source models, to proprietary hosted LLM models. If hosting a model locally, you generally need to have GPU/accelerator hardware available. Open source tools that can be used to locally host LLM models include RamaLama, llama.cpp, and Ollama. There are a number of open source LLM models capable of tool calling. These include models such as gpt-oss-20b and Granite 4 small.
Once you've installed your preferred AI agent application, the next step is to install the linux-mcp-server and configure your AI agent application to use it. The linux-mcp-server Github page includes installation instructions, and configuration details for Goose and Claude Desktop.
Use cases for linux-mcp-server
NOTE
The example scenarios below include LLM generated output. The output is presented here as it was generated by the AI systems cited so you can assess the quality of the output they are capable of, particularly in a non-cloud, self-hosted scenario.
The sample LLM output provided here is not intended to be run by readers without the same level of review we recommend anyone perform on AI generated content prior to use on their systems.
Dear Fedora, why are you so slow today?
Has this happened to you? Time to hop on a call and give a demo. You're pumped. It's your go-time aaaaand… your system starts lagging. Folks on the call say your video is choppy or they can't understand you. OH NO.
You've got to assess what's up, quickly. Run `top`, check `dmesg`, check your network connection (read the man page for `netstat` because you can't remember the flag you want), check `journalctl`, cross-reference what you're seeing, then start killing processes, restarting services, reloading kernel modules willy-nilly based on hastily-crafted theories, see if it improves…
This is a case where you could actually ask the system to tell you why it's slow and give it the ability to do the analysis via linux-mcp-tools. The LLM you connect with won't just run the commands through the MCP server; it will understand what the numbers it gets means in context and be able to explain in human terms.
So let's start working with a relatively new laptop. It's a Thinkpad T14S with the AMD Ryzen
AI Pro 7 ( Ryzen
AI 360 chip.) Recently one of the wifi networks it must connect to regularly was upgraded. It now has issues with the network connection stability. So let's talk to Goose + gpt-oss:20b + linux-mcp-server about it. Here's the initial prompt I used:
My Wifi doesn't work very well. It cuts out after a few minutes. Help me fix it. Can you find the error messages in the system logs and diagnose the problem?
It responded with the following:
I'll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.
LLM output 
I'll help you diagnose your WiFi connectivity issues by examining the system logs for error messages related to your network interfaces and wireless connectivity. Let me start by gathering information about your system and checking the relevant logs.
It then made a series of tool calls, including Get System Information, Get Network Interfaces, Get Journal Logs, Get Hardware Information, Get Service Status service_name:NetworkManager, Get Service Status service_name:wpa_supplicant, Read Log File. The result was this analysis, which is the actual problem I was hoping it could find!
LLM output 
Problem Summary
Your ATH12K PCI (Qualcomm 802.11ax) wireless card repeatedly reports
every few minutes, which triggers a drop of the wireless link. The driver is trying to enqueue an RX buffer for the hardware but fails with errno ‑28.
‑28 →
-ENOMEM(out‑of‑memory for the driver buffer); the kernel cannot allocate a DMA‑coherent RX descriptor.
Likely Root Causes
| Cause | Evidence / Typical Scenario | Fix / Work‑around |
|---|---|---|
| Driver bug or missing patch | The kernel's ath12k driver has had a long‑running issue with RX ring management in older 5.15/5.4 series. | Update the kernel or apply the latest patch from the
linux
tree (5.18+ or the
ath12k
backports). |
| Out‑of‑memory in the driver | The error itself is "‑28" - a memory‑allocation failure inside the driver. | Reduce the number of RX descriptors, or enable fast‑RX disabled mode (
modprobe ath12k_pci ath12k_pci_disable_fast_rx=1
). |
| Firmware mismatch / corruption | Old firmware (
ath12k_hwgen
files) don't match the driver version. |
Reinstall firmware from your distro (
sudo apt‑install --reinstall linux‑firmware
) or copy the latest from kernel source. |
| System memory pressure | If many big processes run, DMA‑coherent memory pool can be exhausted. | Free RAM, close memory‑heavy apps, or add swap. |
| ACPI/PCIe power‑management quirk | Some laptops throttle the Wi‑Fi device after idle, resetting the buffer queue. | Add
pci_bus_reset = off
or set
ath12k_pci_disable_ps=1
in a modprobe conf. |
| Hardware issue (e.g., faulty PCIe slot or NIC) | Persistent failure after multiple driver/kernel upgrades. | Test on another machine/PCIe slot or replace the card. |
Diagnostic Checklist
- Kernel & Driver Version
uname -r
modinfo ath12k_pci | grep ^version: - Driver Parameters
cat /sys/module/ath12k_pci/parameters/*
- See if
ath12k_pci_disable_fast_rxor similar is already set. - Firmware Location
ls /lib/firmware/ath12k/ath12k/ar9009/ | grep wlan0 | head
- If the files are missing or older than the driver, copy newer ones from
/lib/firmwareof a newer kernel. - Kernel Log Around the Error
sudo dmesg --ctime | grep -A3 'ath12k_pci 0000:c2:00.0'
- Observe if there are any other "-ENOMEM" or "resource exhaustion" messages.
- Memory Usage Stats
free -h
vmstat 1 5 - PCIe Latency / Link State
sudo lspci -vvv -s c2:00.0 | grep -iE "link|latency"
Quick‑Fix Path (Try in this order)
| Step | Command | What it does |
|---|---|---|
| 1 |
sudo apt update && sudo apt upgrade linux-firmware
|
Refresh firmware to the latest distro version. |
| 2 |
sudo apt upgrade linux-image-$(uname -r)
|
Apply latest kernel with patched ath12k driver (or switch to 5.18+ if still on 5.15). |
| 3 |
echo "ath12k_pci ath12k_pci_disable_fast_rx=1" | sudo tee /etc/modprobe.d/ath12k.conf
|
Force the driver to use a more conservative RX scheme. |
| 4 | Reboot and monitor:
dmesg -T | grep ath12k_pci
|
Verify the error disappears. |
| 5 | Optional: test on another machine or use a USB‑WiFi dongle (USB 802.11ax / 802.11ac) as a temporary workaround. | Ensure the issue is not hardware‑specific. |
**Tip:** After reboot, you can also verify driver parameters:
Advanced Debugging (if basic fixes don't help)
- Enable debug logs
sudo bash -c 'echo 1 > /sys/module/ath12k_pci/parameters/debug'
sudo dmesg -T | grep ath12k - Check PCIe device state
sudo lspci -vv -s c2:00.0
- Use
ethtoolon the Wi‑Fi interfacesudo ethtool -S wlp4s0
- Look for firmware logs
grep -i 'ath12k' /var/log/syslog
Bottom Line
The "failed to enqueue rx buf: -28" is an internal driver allocation failure that typically follows one of two paths:
- The driver or firmware is out of date → upgrade kernel/firmware.
- The driver configuration is too aggressive for your system's memory budget → tweak module parameters or free RAM.
If you're still stuck after following the quick‑fix path, it's worth capturing more detailed logs with the above diagnostic commands and sharing them. We can then cross‑reference the exact kernel version/driver commit to see if a known patch exists.
Feel free to let me know which step you've tried or if you encounter any new log messages, and we'll dig deeper!
Not too bad an analysis and set of debugging steps! I'll follow up in the comments and let you know if the solution works.
Where'd my disk space go, Fedora?
Trawling through `du` on the command line, converting the numbers in your head, sorting them - it can be tedious. We even have graphical tools like `baobab`, but it takes time to load in the results and explore the data. And sometimes you might have questions it can't answer in terms of the risk of deleting a specific directory, or the age of a specific file. It's easier to be sloppy and just let the disk fill up. But there comes a time where that is no longer an option.
You can ask the system using the linux-mcp-server to analyze your disk usage, give you a hitlist of the top space-eating places on the file system, and give you advice with a risk analysis of how to clean it up.
Here's my prompt:
I need help analyzing disk usage on my system. Can you: 1. Show me the current disk usage across all filesystems using get_disk_usage 2. Use list_directories_by_size to show me the 10 largest directories (this will help identify where disk space is being consumed) 3. Check if there are any large log files consuming space using get_journal_logs or read_log_file 4. Review running processes with list_processes to see if any are consuming excessive resources or creating temporary files After gathering this information, help me identify potential space-saving opportunities and assess the safety of cleaning up specific directories. Please don't only examine top-level directories. I want you to go deep if needed to find out where the largest files are!
I ran this prompt on my Fedora 42 system using linux-mcp-server with Goose connected to locally-served gpt-oss:20b, and here's the output I got:
LLM output 
Disk‑space overview (as of Nov 24 2025 15:21)
| Filesystem | Size | Used | Avail | Use % | Mounted on |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | / |
| /dev/mapper/luks‑61cedb0e… | 952.3 GB | 548.9 GB | 399.6 GB | 57.9 % | /home |
| /dev/nvme0n1p2 | 973.4 MB | 462.8 MB | 443.4 MB | 51.1 % | /boot |
| /dev/nvme0n1p1 | 598.8 MB | 19.3 MB | 579.6 MB | 3.2 % | /boot/efi |
Overall usage is comfortably below 60 % of a 952 GB volume, so immediate capacity pressure isn't a concern. The biggest contributors to disk space today are in the ~/. hierarchy.
1. Biggest directories on the system
| Path (relative to the mount point) | Size (≈) | Notes |
| ~/ - User home (2 mounts: /home + /) | 1 TB total | 57 % used; the bulk of the space is in ~/ |
| ~/duffy/.local/share | 238 GB | Containers sub-dir, followed by Trash (7GB) - typical podman/docker container images |
| ~/duffy/.local/share/containers | 238 GB | Container layers, images, root filesystems - the prime candidate for cleanup |
| ~/duffy/.local | 266 GB | share (237 GB) dominates it |
| ~/duffy/.local/share/containers (inside share) | 238 GB | Same as above - just a different view |
| ~/duffy/.local/lib | 13 GB | Likely a virtual‑environment library set |
| ~/duffy/.local/bin | 4 GB | Helper binaries |
| ~/duffy/.local/share/Trash | 7 GB | User‑deleted items still resident on disk |
| ~/duffy/.local/share/containers (nested) | 238 GB | Same as above; redundant listings from recursive depth‑1 scans |
| ~/duffy/.local/share (top‑level) | 238 GB | containers is the absolute largest item |
Take‑away - 75 % of the 238 GB live inside three nested directories:
- ~/duffy/.local/share/containers (238 GB) → Rooted in Podman/Container‑Store
- ~/duffy/.local/share (238 GB) → Same data exposed at a higher level
- ~/duffy/.local/share/Trash (7 GB)
2. Possible space savers
| Category | Recommendation | Rationale |
| Containers | podman system prune -a (or docker system prune -a if Docker is in use) | Removes unreferenced images, containers, and caches. This can reclaim 200-250 GB if most containers are outdated or no longer referenced. |
| Trash | gio trash -empty | The 7 GB in Trash is still taking physical space; simply emptying it will free that amount. |
| Large libs/binaries | Check ~/duffy/.local/lib - 13 GB, and ~/duffy/.local/bin - 4 GB | If these are not actively used by a project, consider uninstalling or moving them to a secondary, less‑frequented store. |
| Ramalama & UV | 9 GB (ramalama), 8 GB (uv) | Possibly temporary files or caches from development tools. Inspecting the contents of these directories (du -h) can reveal if they are still needed. |
| Other caches | pnpm store prune, virtualenv or pip cache purge | Development tool caches often accumulate; they're usually safe to delete once you're done with the current development sessions. |
| Logs | The system journal shows normal activity, and syslog access is blocked by policy. | Systemd journal stores are rotated automatically; no urgent action required. |
| Boot partitions | Not relevant - they're low‑usage (boot/efi only 3 % used). | No action needed. |
3. Disk‑IO perspective
- Reads: 111.8 GB; Writes: 85.6 GB since boot (≈ 1.2 TB total).
- If writes are high relative to free space, consider enabling a tmpfs overlay for temporary files or moving large data to a separate, faster SSD. But in this case, writes are not approaching the 399 GB free.
4. Suggested cleanup workflow
# 1. Empty Trash
gio trash --empty
# 2. Prune unused containers/images
podman system prune -a # or docker system prune -a
# 3. Remove leftover caches
pnpm store prune # if pnpm is installed
pip cache purge # for Python
virtualenv --clean # optional
# 4. Inspect large "RAM" directories manually if you need deeper cleanup
du -h --max-depth=1 ~/duffy/.local/share/containers
Tip: After each step run df -h /home or du -sh ~/duffy/.local/* to see the impact.
5. Safety checklist
| Action | Why it's safe (or risk) |
| Emptying Trash | Deletes only user‑deleted files; confirm you don't need the content. |
| podman system prune -a | Deletes container images, containers, and volumes that are not referenced by any running or stopped container. Verify with podman ps -a before pruning. |
| Removing lib/bin from .local | Only safe if you're sure those libraries/bin files aren't part of a running application. |
| Caution with tmpfs or moving large directories | If you move a directory on‑the‑fly, ensure no running application depends on that path. |
Bottom line
- Current free space: ≈ 400 GB on both / and /home.
- Largest consumptions: User‑space under ~/duffy/.local/share/containers (≈ 238 GB).
- Actionable clean‑ups: Empty Trash, prune unused container images, and review large libraries/binaries. This should reclaim over 200 GB and bring the usage from 57.9 % down to roughly 40‑45 % - plenty of headroom for the future.
Feel free to ask what next steps you'd like to dig into (e.g., detailed contents of the containers dir, specific application logs, or targeted pruning commands).
Upgrade planning
So you may have noticed a little detail above - the system is a Fedora 42 system… and Fedora 43's been out a month now!
So, time to upgrade.
This example shows where we have some tools missing from the set provided in the linux-mcp-server. We're including it for two reasons:
- So you can see how this works manually
You can see that even when specific tools you might not need are available in the MCP server, you can have the response give you instructions on commands to run on your own, and copy/paste the command output back into your chat to get analysis alongside the data the system is able to pull via the MCP tool calls; - To encourage you to submit additional tools to our project!
We would love your additions to the project! Here's where to get started: https://github.com/rhel-lightspeed/linux-mcp-server/blob/main/docs/CONTRIBUTING.md
Here's the prompt I started with, with the same Goose + gpt-oss:20b + linux-mcp-server combination:
You are a Linux system administrator assistant analyzing a Fedora system for upgrade readiness. TASK: Examine this Fedora 42 system and provide a comprehensive upgrade readiness report for Fedora 43. ANALYSIS CHECKLIST: 1. Check current Fedora version: cat /etc/fedora-release 2. Review system updates status: dnf check-update 3. Identify third-party repositories: dnf repolist 4. List installed packages from non-Fedora repos: dnf list installed | grep -v @fedora 5. Check for broken dependencies: dnf check 6. Review disk space on root partition: df -h / 7. Check for unsupported or deprecated packages 8. Identify custom kernel modules: lsmod | grep -v "^Module" 9. Review SELinux status: sestatus 10. Check for pending system updates: dnf upgrade --refresh --assumeno REPORT FORMAT: # Fedora 43 Upgrade Readiness Report ## Current System Status - Fedora version: [version] - Kernel: [kernel version] - Updates status: [current/outdated] ## Potential Issues [List blocking issues with HIGH/MEDIUM/LOW severity] ## Third-Party Software [List non-Fedora packages that may need attention] ## Recommendations [Specific pre-upgrade steps needed] ## Overall Readiness: [READY/NEEDS ATTENTION/NOT READY] Run the necessary commands and provide this analysis. Be specific about any issues found and give actionable recommendations.
Now, right away the model came back to me to complain it doesn't have access to `dnf`, `cat`, etc. And that's expected here. What it did was give me a list of homework to run for it to complete the analysis… for example, `dnf check-update` and `cat /etc/fedora-release`. I had a little back and forth in Goose with the model where it would ask me to run a command and I'd copy the output into the context. This resulted, finally, in the following report:
LLM output 
Fedora 43 Upgrade Readiness Report
Analyzed System - Fedora 42 (Kernel 6.17.7‑200.fc42.x86_64)
Date - 2025‑11‑24
1. Current System Status
| Item | Value |
| Fedora release | 42 (Adams) |
| Kernel | 6.17.7‑200.fc42.x86_64 |
| Root filesystem | 953 GB LUKS, 58 % used (411 GB free) - > 15 % free |
| /var /usr | Same as root partition (mounted the same LUKS device) |
| SELinux | enabled (policy targeted), currently permissive |
| System‑wide packages | No held packages (dnf versionlock list empty) |
| System modules | No modules held. |
TL;DR - The base system is clean; the kernel is up‑to‑date for 42, there is ample disk space, and there are no version‑locked packages.
2. Third‑Party Repos & Packages
| Repository | Description | Current dnf repolist status |
| rpm-fusion-free, rpm-fusion-nonfree, rpm-fusion-updates | Widely used RPM‑Fusion components | Enabled |
| google-cloud-cli | Google Cloud SDK (RPM built for EL 10) | Enabled |
| visual-studio-code | Microsoft VS Code RPMs | Enabled |
| command‑line‑assistant, google‑chrome, PyCharm, unsupported‑fedora‑packages, goose, leaktk | Various Copr builds (mostly Fedora‑42 based) | Enabled |
What we need to verify
- Is a Fedora 43 build available for each of the non‑Fedora repos above?
- Does google-cloud-cli have a Fedora 43‑compatible package? (EL 10 build may not be usable).
- Are there any el10‑specific dependencies that could surface during the upgrade?
- Any custom kernel modules that will require re‑compilation against the 43 kernel.
3. Potential Issues & Severity
| Issue | Severity | Why it matters | Immediate Remedy |
| Non‑Fedora packages (e.g., google‑cloud‑cli) | MEDIUM | May contain packages built for EL 10; could conflict with Fedora 43 libs. | Verify if a Fedora 43 build exists or plan to remove/re‑build it. |
| Third‑party repos without 43 builds | MEDIUM | dnf system-upgrade pulls all enabled repos; lacking 43 packages causes transaction failure. | Disable such repos temporarily (dnf config-manager -set-disabled <repo>) or enable the 43 stream when available. |
| Custom kernel modules | LOW | Modules compiled against 42 kernel won't load on 43; services may drop. | Re‑compile or patch modules after upgrade. |
| Broken dependencies reported by dnf check | HIGH | Would block the upgrade transaction. | Run sudo dnf check now; fix any reported issues. |
| Insufficient disk space | HIGH | Upgrade scripts need > 15 % free. | Not an issue (58 % free). |
Current High‑Risk Items - None detected yet.
Next Action - Confirm each third‑party repo has 43‑compatible packages and set SELinux to enforcing.
4. Recommendations (Pre‑Upgrade Checklist)
| Step | Command | Purpose |
| Confirm 43‑stream packages | `dnf list -available * | grep <repo-id>` |
| Verify SELinux enforcement | sestatus | Should show enforcing. |
| Check for broken dependencies | sudo dnf check | No errors should appear. |
| Refresh all repos | sudo dnf upgrade -refresh | Pull latest metadata. |
| Dry‑run upgrade | sudo dnf system-upgrade download -releasever=43 -allowerasing | Detect any missing packages or conflicts. |
| Optional: Disable problematic repos | sudo dnf config-manager -set-disabled <repo> | Prevent upgrade crash if a repo has no 43 build. |
| Persist SELinux config | sudo sed -i 's/SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config | Make enforcement permanent. |
5. Post‑Upgrade Actions
- Reboot into the new kernel (dnf system-upgrade reboot).
- Re‑compile any custom kernel modules against the new kernel (yum install kernel-devel-$(uname -r) then rebuild modules).
- Re‑enable any disabled repos once the upgrade completes.
- Verify critical services (systemctl status <service>) and check logs.
- Run sudo dnf distro-sync to ensure all packages are the latest from Fedora 43.
6. Overall Readiness
| Criteria | Status | Comment |
| Disk space | Ready | 58 % free |
| Package health | Ready | No held or broken packages |
| Third‑party repos | Conditional | Verify 43‑compatibility |
| Custom modules | Pending | Need to identify modules and re‑compile |
| Final verdict | READY (after addressing above points) |
Next step - Run the three verification commands below and share the output with me:
sudo dnf check
sudo dnf repolist
dnf list installed | grep -v @fedora
With those outputs I can pinpoint any remaining blockers and give you a final, ready‑to‑proceed plan.
Happy upgrading!
Give it a try, let us know what you think!

You can see from these few examples that tool calling with LLMs is a valuable tool for troubleshooting Linux systems. We could use your help building this and making it awesome! How can you help?
- Give it a try, let us know what you think, file any bugs you find, and let us know what tools are missing that you could use! You can respond in the comments here, file a bug, or chat with us on Fedora matrix.
- We're primarily working with Goose as our client, but if you have another preferred client and want to help us support it better, we'd love to work with you!
- Get involved in the linux-mcp-project generally, we'd love to see your PRs!
- Let us know what you'd like to see in the future. What workflows would you like to see supported? How do you see this making your Fedora or overall Linux experience better? What larger workflows do you see this plugging into?
Join us upstream at https://github.com/rhel-lightspeed/linux-mcp-server! And come chat with us in the Fedora AI/ML SIG chat room on Matrix!
10 Dec 2025 8:00am GMT
Fedora Infrastructure Status: Fedora Copr outage - updating servers
10 Dec 2025 7:00am GMT
Chris Short: Short Family's Ultimate Holiday Movie Marathon: 29 Holiday Films
10 Dec 2025 5:00am GMT
09 Dec 2025
Fedora People
Michael Catanzaro: Significant Drag and Drop Vulnerability in WebKitGTK
WebKitGTK 2.50.3 contains a workaround for CVE-2025-13947, an issue that allows websites to exfiltrate files from your filesystem. If you're using Epiphany or any other web browser based on WebKitGTK, then you should immediately update to 2.50.3.
Websites may attach file URLs to drag sources. When the drag source is dropped onto a drop target, the website can read the file data for its chosen files, without any restrictions. Oops. Suffice to say, this is not how drag and drop is supposed to work. Websites should not be able to choose for themselves which files to read from your filesystem; only the user is supposed to be able to make that choice, by dragging the file from an external application. That is, drag sources created by websites should not receive file access.
I failed to find the correct way to fix this bug in the two afternoons I allowed myself to work on this issue, so instead my overly-broad solution was to disable file access for all drags. With this workaround, the website will only receive the list of file URLs rather than the file contents.
Apple platforms are not affected by this issue.
09 Dec 2025 3:29pm GMT
Fedora Magazine: Flock 2026 CfP open now until Feb 2nd 2026

Apply now for the Flock to Fedora 2026 Call for Proposals (CfP) at cfp.fedoraproject.org. This year, the submission deadline for the Flock CfP is Monday, February 2nd, 2026.
Flock 2026 registration is open
Last month we announced that we'll be convening again in Prague for Flock 2026 in June. Everyone interested in attending can head over to the Flock 2026 website and register today! For those of you who want to contribute to Flock by presenting your thoughts and ideas in front of your fellow contributors, we've got some inspiration for you in the form of updated proposal themes.
Flock 2026 proposal themes
This year's proposal themes are inspired by Fedora's four foundations:
- Freedom: The Open Frontier - This theme explores how Fedora pushes the boundaries of technological freedom. We invite proposals on FOSS approaches to Artificial Intelligence, the advancement of open hardware like RISC-V, the development of open standards, and the protection of data privacy. Sessions should focus on how our work in the Fedora Project creates a more free and collaborative technological world for everyone.
- Friends: Our Fedora Story - This theme celebrates the people and practices that make our community unique. We seek proposals that share stories of mentorship, successful team collaboration, and effective onboarding within Fedora. Collaboration is key to our success. Sessions about our partnerships with other FOSS communities should center on the mutual benefits and the positive impact these relationships have on the Fedora Project.
- Features: Engineering Fedora's Core - As a contributor conference, this theme dives deep into the craft of building our distribution and other Fedora outputs. We welcome sessions on improvements to our infrastructure, release engineering processes, quality assurance, packaging, and community tooling. This is the place for technical talks that showcase our engineering excellence and the collaborative work that makes Fedora's deliverables possible, from code to final artifact.
- First: Blueprint for the Future: Fedora Linux 45 & 46 - This theme focuses on the near-term innovations that will define the next generation of Linux. With the next few Fedora Linux releases serving as the foundation for RHEL 11 and EPEL 11, this is a critical time. We are looking for forward-looking technical talks on the changes, features, and architectural decisions in F45 and F46 that will shape the future of the operating system, from the community desktop to the core of the enterprise platforms.
These themes are here to help get you thinking about topics you'd like to present. If you have something you want to talk about that doesn't quite fit neatly into these themes, but you feel it belongs at Flock, go ahead and submit anyways! The reviewers are open to alternative topics. They are on the look out for topics that Fedora contributors are interested in discussing.
Flock financial travel assistance available
Financial travel assistance applications are now open as well. When you go to register to attend on the Flock 2026 website, you should also see links on how to apply for travel assistance if you need it. Financial assistance will be open until March 8th (several weeks after CfP closes on Febuary 8th). This is to give those with accepted talks an opportunity to figure out if they'll need travel assistance.
09 Dec 2025 8:00am GMT
08 Dec 2025
Fedora People
Fedora Infrastructure Status: rdu2 to rdu3 datacenter move
08 Dec 2025 1:00pm GMT
Chris Short: Common Display Resolutions
08 Dec 2025 5:00am GMT
06 Dec 2025
Fedora People
Kevin Fenzi: infra weekly recap: early december 2025
hey everyone, it's saturday so time for another recap of adventures in fedora infrastructure and other fedora areas.
scrapers
I started a discussion thread about the current scrapers we are dealing with. To summarize, anubis has cut out a bunch of them and really helped out quite a lot. It has caused some issues with clients as well, but we have been working thought those as we hear about them. The remaining scrapers are large botnets of browsers, probibly running on end user machines. Those are more troublesome to deal with.
The discussion thread is at: https://discussion.fedoraproject.org/t/scrapers-and-ideas-for-how-to-deal-with-them/175760 if anyone would like to read or contribute.
We had another run in with them eariler this morning. A great way to spend saturday morning, but I did look more carefully this time. The main cause of issues was them hitting src.fedoraproject.org and it's /history/ and /blame/ endpoints. This was causing the backend to have to do a somewhat expensive git blame/history call to the local repos and since it took a bit to come back requests piled up and latency went way up. I have for now blocked those endpoints in the src.fedoraproject.org web interface. This brought everything back to normal. If you need to do those things, you can easily clone the git repo locally and do them.
rdu2-cc to rdu3 datacenter move
This last week, I moved pagure.io (virtually) to the new datacenter. Unfortunately it didn't go as smoothly as I had hoped. All the data synced over in about 15minutes or so, but then I tried to test it before switching it live and it just wasn't allowing me to authenticate on git pushes. Finally the light bulb went on and I realized that pagure was checking for auth, but it wasn't 'pagure.io' yet because I hadn't updated dns. ;( It's always DNS. :) After that everything went fine. There were a few loose I had to fix up the next day: mirroring out was not working because we didn't have ssh outgoing listed as allowed. Uploading releases wasn't working due to a selinux labeling issue, and finally our s390x builders couldn't reach it because I forgot they needed to do that. Hopefully pagure.io is all happy now and I even gave it more resources in the new dc.
Monday the actual physical move happens. See: https://pagure.io/fedora-infrastructure/issue/12955 for more details. Mostly, folks shouldn't notice these machines moving. abrt submissions will be down, and download-cc-rdu01 will be down, but otherwise it should be a big nothing burger for most folks. Machines will move monday and we will work tuesday to reinstall/reconfigure things and bring it all back up.
Matrix outage on dec 10th
There is going to be a short outage of our fedora.im and fedoraproject.org matrix servers. We are migrating to the new MAS setup (Matrix Authentication Server). This will allow clients to use things like element-x and also is a important step we wanted to complete before moving forward on deploying our own matrix servers.
forge migration
A number of groups have already moved over to forge.fedoraproject.org from pagure.io. I really was hoping to move infrastructre, but haven't had the cycles yet. We do have the orgs created now and are planning on moving our docs over very soon. I don't know if we will move tickets before the end of the year or not, but we will see.
December of docs
So, I committed myself to doing a docs pr/issue/something every day in December, and so far I am doing so! 6 days and 6 PR's and more tickets updated. Hopefully I can keep it up.
comments? additions? reactions?
As always, comment on mastodon: https://fosstodon.org/@nirik/115674367344830186
06 Dec 2025 7:29pm GMT
Fedora Infrastructure Status: src.fedoraproject.org access degraded
06 Dec 2025 4:30pm GMT
Phil Wyett: Been a while - Update
Have not been the best health wise recently, we are enjoying life and carrying on though.
Because the Fedora Project removes access levels after 12 months of inactivity, I was required to file a ticket as a returning developer of the 'packager' group. This was processed very quickly by Kevin Fenzi and all my access level restored. Kevin is always extremely helpful though he is always busy ... busy.
Current activities are bringing packages from Fedora into Extra Packages for Enterprise Linux (EPEL) in order to have more science and astronomy packages available on Enterprise Linux (EL).
Java being a language I do prefer to code, I am also trying to get useful packages into or back into Fedora. Once done they can be looked at possible inclusion in EPEL.
I have another couple of projects in the early stages and more details will follow in future posts. One I am very excited about and will involve design, engineering and manufacture of the prototype.
Watch this space for this years Christmas sweater post.
06 Dec 2025 10:11am GMT
05 Dec 2025
Fedora People
Fedora Community Blog: Important Update: Fedora Linux 43 Election Schedule Extended

TL;DNR: The Fedora Linux 43 Election schedule has been extended. Voting will now take place from 15 December 2025 through 7 January 2026.
Due to unforeseen delays in the interview coordination process, we are adjusting the election timeline. To ensure all candidates have ample opportunity to present their platforms and the community has sufficient time to vote, the election period will now extend through the year-end holidays.
Please mark your calendars with the following new critical dates:
New Election Schedule
- Interview Submission Deadline (Extended): Now through Friday, 12 December 2025 at 23:59 UTC (Candidates: Please ensure your responses are submitted by this time.)
- Voting Setup & Interview Publishing: Monday, 15 December 2025 (Voter guides and interviews will be published to the community on this date.)
- Voting Period Opens: Monday, 15 December 2025
- Voting Period Closes: Wednesday, 7 January 2026 at 23:59 UTC
Context on the Schedule Change
Transparency is an important value of the Fedora Project, and I want to provide context on why this shift was necessary. I recently returned from two weeks of bereavement leave on Wednesday, 3 December. During my absence, the coordination work required to collect and process nominee interviews for the Fedora Engineering Steering Committee (FESCo) did not occur as originally planned.
Consequently, we missed the window to launch the elections today, Friday, 5 December. Rather than rushing the process, we are opting to extend the timeline. This ensures that our candidates are properly featured and that the election remains fair and accessible to all voters, despite the holiday season overlap.
The official Fedora schedule calendar is being updated to reflect these changes shortly. Thank you for your patience and understanding.
The post Important Update: Fedora Linux 43 Election Schedule Extended appeared first on Fedora Community Blog.
05 Dec 2025 3:43pm GMT
Fedora Community Blog: Community Update – Week 49

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: December 1 - December 5 2025
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure.
It's responsible for services running in Fedora infrastructure.
Ticket tracker
- Pagure.io migration happened earlier in the week, expected disruption during that (https://status.fedoraproject.org for details)
- RDU2-CC -> RDU3 DC move next week
- OpenID finally has a date to be retired - we have a separate OpenID instance of Ipsilon that serves a warning (ticket)
- Weblate legal issues raised by the community to the Council
- Survived Thanksgiving without major fires

- Ongoing work on the Keycloak migration
CentOS Infra including CentOS CI
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It's responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker
- Migrate dev repo to rdu3
- Mirror: Update CERN IPs
- Decommission RDU2 hardware (unused)
- Modify backup script to cover new Netapp NFS storage plan
- [SN#1579] Migrate CentOS Infra/services running from community cage to new DC
- Create calligrabot pull request with signing fix
- Migrate calligrabot
Release Engineering
This team is taking care of day to day business regarding Fedora releases.
It's responsible for releases, retirement process of packages and package builds.
Ticket tracker
- Please update f43-image-builder target to use an appropriate Destination Tag.
- set released_on date field in Bodhi Release metadata
RISC-V
- (Things are chugging along.)
- F43 rebuild is still ongoing. The diff with primary arch is now about ~1K packages. Still ironing out some rough edges. (A bug with "debugedit" is affecting a number of packages.)
- Jason Montleon published some board-specific F43 kernels.
- We're working on putting together the RISC-V devroom at FOSDEM.
Forgejo
Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker
- Handled empty dates in Pagure milestone migration in the Forgejo upstream [Issue] [PR]
- Initial preparation work being carried out to deploy the Forgejo "dist-git" instance - konflux pipelines for distgit are ready, with images with stable fedora available on quay.
- 5+ new teams have organizations on Forge now.
- Forgejo runners can be scoped to global/organization/individual on staging.
- [Docs] Starting to migrate select repositories, first one to be the Release Notes
QE
- A first QE repo got migrated from Pagure to Fedora Forge production server, as a guinea pig. A set of helper scripts were created to perform necessary post-migration tasks (see more in the AI section).
- New test suite for Fedora Media Writer has been finished and is waiting for review
- FreeIPA webUI test day is ongoing
- Finally fixed a longstanding bug that broke all openQA encrypted install test cases on aarch64 (with an assist from Jeremy Linton)
If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.
The post Community Update - Week 49 appeared first on Fedora Community Blog.
05 Dec 2025 2:00pm GMT
Remi Collet: 🎲 PHP version 8.3.29RC1, 8.4.16RC1 and 8.5.1RC1
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.1RC1 are available
- as base packages in the remi-modular-test for Fedora 41-43 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
RPMs of PHP version 8.4.16RC1 are available
- as base packages in the remi-modular-test for Fedora 41-43 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
RPMs of PHP version 8.3.29RC1 are available
- as base packages in the remi-modular-test for Fedora 41-43 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.2 is now in security mode only, so no more RC will be released.
ℹ️ Installation: follow the wizard instructions.
ℹ️ Announcements:
- PHP 8.5.1RC1 available for testing
- PHP 8.4.16RC1 available for testing
- PHP 8.3.29RC1 available for testing
Parallel installation of version 8.5 as Software Collection:
yum --enablerepo=remi-test install php85
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Parallel installation of version 8.3 as Software Collection:
yum --enablerepo=remi-test install php83
Update of system version 8.5:
dnf module switch-to php:remi-8.5 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.3:
dnf module switch-to php:remi-8.3 dnf --enablerepo=remi-modular-test update php\*
ℹ️ Notice:
- version 8.5.1RC1 is in Fedora rawhide for QA
- EL-10 packages are built using RHEL-10.1 and EPEL-10.1
- EL-9 packages are built using RHEL-9.7 and EPEL-9
- EL-8 packages are built using RHEL-8.10 and EPEL-8
- oci8 extension uses the RPM of the Oracle Instant Client version 23.9 on x86_64 and aarch64
- intl extension uses libicu 74.2
- RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
- versions 8.3.29, 8.4.16 and 8.5.1RC1 are planed for December 18th, in 2 weeks.
Software Collections (php83, php84, php85)
Base packages (php)
05 Dec 2025 8:58am GMT