A Fedora reference, built while moving my daily driver over

I moved my daily-driver laptop to Fedora this week, dual-booted alongside the old Windows install. Before touching anything production-shaped on it, I put together the reference I wanted to have on hand: not a full manual, just the commands and gotchas that actually matter day to day, organised the way I'd reach for them.

This is that reference, trimmed to what earns its place in a blog post rather than a wiki page. It leans on general Fedora documentation and my own sysadmin background rather than incidents on this specific machine yet. Those will get their own write-ups as they happen.

Package management, and the undo button#

Day-to-day dnf is what you'd expect: search, install, remove, upgrade. Three things are worth knowing before you need them, not after.

dnf provides finds what owns a missing command.

dnf provides /usr/bin/<binary>
dnf provides '*/<filename>'

Faster than guessing a package name from a command name.

dnf history is the actual recovery path after a bad upgrade, not a backup or a snapshot.

dnf history
dnf history info <id>
dnf history undo <id>

distro-sync realigns installed packages to whatever the repos currently offer. Mixing in a third-party repo (RPM Fusion, a COPR) can leave some packages ahead of or behind the rest of the system, and this is the fix.

dnf distro-sync

COPR builds are unsigned community builds. Treat them as untrusted by default, the same way you'd treat a random script off the internet.

systemd and journalctl: the first ten minutes of any incident#

Whatever actually broke, this is roughly the order I'd check things in.

systemctl status <service>
journalctl -u <service> -b --no-pager
journalctl -b -1 -p err
systemctl --failed

journalctl -b -1 -p err (errors from the previous boot) is the first thing worth checking after an unexplained reboot or crash. systemctl --failed lists every unit that failed to start on the current boot, which catches problems that never surface as a support ticket because nothing downstream needed that particular service yet.

daemon-reload after editing any unit file is easy to forget and produces a confusing "it's not applying" symptom that looks like anything but a forgotten reload.

systemctl daemon-reload

SELinux: usually the cause, rarely the message#

Fedora enforces SELinux by default, and it is a common cause of "permission denied" errors that look like ordinary file permission problems: the kind where chmod and chown are both already correct and the error persists anyway.

getenforce
ausearch -m avc -ts recent
sealert -a /var/log/audit/audit.log

sealert (from setroubleshoot-server) explains a denial in plain language and usually names the fix directly. setenforce 0 disables enforcement temporarily for diagnosis. If the problem disappears, that confirms SELinux is the cause, and the next step is fixing the context or boolean, not leaving enforcement off:

semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web

restorecon restores whatever context the policy says a path should have. chcon sets one by hand and gets silently undone by the next relabel: useful for a quick test, wrong for anything meant to stick.

Why df -h lies on Btrfs#

Fedora Workstation defaults to Btrfs, and df -h reports space in a way that doesn't match how Btrfs actually allocates it. Shared extents, snapshots and subvolumes all complicate what "free space" even means from a single number.

btrfs filesystem usage /
btrfs filesystem df /

btrfs filesystem usage is the command that actually answers "how much space do I have," in a filesystem where the honest answer has more moving parts than a single percentage.

firewalld: runtime versus permanent#

Every rule needs deciding twice unless you say otherwise.

firewall-cmd --add-service=http
firewall-cmd --add-service=http --permanent
firewall-cmd --reload

Without --permanent, a rule is runtime-only and gone at the next reload, which is exactly the property you want while testing, and exactly the trap if you forget to make it permanent afterward. Test with a runtime rule, confirm it does what you meant, then commit it.

Networking: nmcli over ip for anything permanent#

ip changes are not persistent. nmcli writes a connection profile that survives a reboot.

nmcli connection modify <name> ipv4.method manual \
  ipv4.addresses 192.168.10.50/24 \
  ipv4.gateway 192.168.10.1 \
  ipv4.dns "192.168.10.1 1.1.1.1"
nmcli connection up <name>

For a quick no-network diagnosis, testing gateway, then public IP, then a DNS name, in that order, isolates layer 2, layer 3 and DNS as three separate questions instead of one vague "the internet is down":

ping -c 3 <gateway>
ping -c 3 1.1.1.1
ping -c 3 google.com

The quick-reference table#

The subset I expect to actually look up more than once:

That last one matters more than its size suggests: a bad /etc/fstab entry can prevent a boot outright, and mount -a catches it while you can still fix it from a running system.

This will grow as I actually hit the SELinux denial, the Btrfs surprise, the driver problem that the reference above only gestures at. Those get their own posts when they happen, with what actually went wrong and how it actually got fixed. This one is the map I brought before the territory.