You hit a wall and need help
You upgraded a package and your desktop environment crashes to the TTY. Or your network manager refuses to connect after a routine update. You know it is not your configuration. You need the package maintainer to see exactly what broke. Filing a bug report feels intimidating because you worry about missing a step or using the wrong terminology. The process is straightforward once you know what the maintainers actually need.
What a bug report actually does
Bugzilla is a database, not a chat room. Maintainers triage hundreds of reports weekly across dozens of components. A report without reproducible steps or version information gets marked NEEDINFO and sits idle. Think of your report as a recipe. If you tell a chef the soup tastes wrong, they cannot fix it. If you tell them you used two cups of salt instead of two teaspoons and the pot boiled over at one hundred degrees, they can adjust the formula. Your job is to provide the exact ingredients and conditions so the maintainer can recreate the failure on their test machine.
Maintainers work with isolated build environments. They do not have your hardware, your custom scripts, or your years of accumulated configuration drift. They need a clean path from a default Fedora installation to the exact moment the failure occurs. Every missing detail forces them to guess, and guesses delay fixes. Provide the exact command you ran, the exact output you saw, and the exact package version you were using. A complete report moves from NEW to ASSIGNED in days. An incomplete report stays open for months.
Run journalctl -xe before you panic. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style because it shows recent log lines and state in one view. Always check status before restarting a service. Restarting clears the buffer and destroys the evidence you need.
Gather the right evidence first
Before you open a browser, run a few commands in the terminal. Maintainers need three things: the exact Fedora release, the exact package version, and the exact error output. Run these commands and save the output to a text file. You will paste it into the report later.
Here is how to collect the baseline system and package information in one pass.
# Identify the exact Fedora release and kernel version
cat /etc/fedora-release
uname -r
# Pull the full package metadata including build date and vendor
rpm -qi <package-name>
# Check recent changelog entries for known fixes or breaking changes
dnf changelog <package-name>
# Extract error-level journal entries from the current boot
journalctl -b --priority=err | grep -i <component>
# Capture recent SELinux access vector cache denials
sudo ausearch -m AVC -ts recent
Save the output to a file named bug-report-info.txt. Do not edit the file. Maintainers need to see the raw output exactly as the system produced it. If the journal output runs longer than twenty lines, truncate it to the first ten lines and the last five lines. Add a comment between them that says # ...output truncated for clarity. Long logs bury the actual failure.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. If you modified a configuration file to work around the issue, attach that file to the report. Maintainers need to see what changed and why.
File the report in Bugzilla
Navigate to the Fedora Bugzilla instance and log in with your Fedora account. If you do not have one, create it at accounts.fedoraproject.org. Select Fedora as the product. Choose the component that matches the package name. Set the version to your current release. Write a summary line that describes the symptom, not the cause. Use a format like Package crashes when opening settings panel. Write the description with clear steps. Attach the log file you generated earlier.
Structure the description in plain paragraphs. Start with a one-sentence summary of the failure. Follow with a numbered sequence of steps that leads directly to the error. State what you expected to happen. State what actually happened. Paste the terminal output in a code block. Attach any screenshots or core dumps. Do not apologize for filing the report. Do not speculate about the root cause. Stick to observable facts.
Here is how to format the description so the triage team can parse it instantly.
Summary: NetworkManager fails to start after upgrading to version 1.42.5
Description:
The system boots to a text console. NetworkManager.service enters a failed state.
The issue occurs immediately after running dnf upgrade --refresh.
Steps to reproduce:
1. Update the system with dnf upgrade --refresh
2. Reboot the machine
3. Check service status with systemctl status NetworkManager.service
Expected behaviour:
NetworkManager starts and connects to the configured interface.
Actual behaviour:
The service exits with code 1. The journal shows a missing interface name.
Relevant output:
[FAILED] Failed to start NetworkManager.service
# ...output truncated for clarity
Submit the form. You will receive a confirmation email with a bug number. Bookmark the link. Check the status after forty-eight hours. If it says NEEDINFO, reply with the requested details. The ticket stays open until someone closes it.
Use abrt for crashes instead of manual reporting. The Automatic Bug Reporting Tool collects a backtrace automatically and can submit directly to Bugzilla. Install it with sudo dnf install abrt abrt-desktop. Enable the daemon with sudo systemctl enable --now abrtd abrt-ccpp. After a crash, run abrt-cli list to view captured reports and abrt-cli report <id> to file them. The tool handles symbol resolution and package metadata for you.
Tag your report with FutureFeature if it is actually an enhancement request rather than a defect. Maintainers track enhancements separately from defects. Mixing them slows down triage.
Verify the submission
After submission, you will get a confirmation email with a bug number. Bookmark the link. Check the status after 48 hours. If it says NEEDINFO, reply with the requested details. The ticket stays open until someone closes it.
Maintainers often ask for a minimal reproduction case. Strip away custom scripts, third-party repositories, and non-essential packages. Test the failure on a fresh virtual machine if you can. A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can. If the issue disappears on a clean install, the problem is likely configuration drift, not a package defect. Note that in your reply. It saves everyone time.
Run journalctl -xe first. Read the actual error before guessing. Half the time the symptom is gone after a single reboot.
Common pitfalls and what the error looks like
People often file bugs for upstream issues, configuration mistakes, or EOL releases. If you see Error: Transaction test error: package python3-3.12.x conflicts with python3-3.13.y, that is usually a dependency resolution issue, not a package bug. Run dnf upgrade --refresh first. The conflict is intentional. Read the next paragraph before forcing.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Check journalctl -xeu NetworkManager.service before filing. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling the policy hides the real problem and breaks security guarantees.
Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. Filing a bug against an EOL release gets closed immediately. Maintainers do not backport fixes to unsupported versions. Upgrade to the current release and test again.
Tag enhancement requests with FutureFeature. Do not mark them as BLOCKER or CRITICAL. Those keywords reserve slots for data loss, security vulnerabilities, and boot failures. Misusing them triggers automated filters and delays real emergencies.
Trust the package manager. Manual file edits drift, snapshots stay. If you patched a binary or replaced a library with a custom build, restore the original files before testing. Maintainers cannot debug a system that deviates from the official repository state.
When to use Bugzilla vs alternatives
Use Bugzilla when you found a defect in an RPM package shipped by Fedora. Use the upstream project tracker when the issue exists in the original software before Fedora packaged it. Use the Fedora Discourse forum when you need help configuring a service or understanding a concept. Use the IRC or Matrix channels when you want real-time discussion about packaging standards. Stay on Bugzilla when you have a reproducible failure and the exact package version.