Why does my fedora fsck the root partition after every dnf "offline"-update?

Ask Fedora
1

for about some weeks my fedora 41 install has been fsck-ing the root partition everytime after i make an upgrade.

i do “offline” (not in the sense of internet) updates via

sudo dnf upgrade --offline --refresh -y && sudo dnf offline reboot -y

and during the reboot after the update everytime a fsck is running nowadays.

i have already manually fsck’ed the root partition from an usb live system but no errors were found.

here are the fsck-related journalctl-entries:

Feb 19 20:45:47 systemd[1]: Starting systemd-fsck-root.service - File System Check on /dev/disk/by-uuid/[uuid]
Feb 19 20:45:47 systemd-fsck[621]: FEDORA_ROOT: recovering journal
Feb 19 20:46:01 systemd-fsck[621]: FEDORA_ROOT: Inode 7995501 extent tree (at level 2) could be narrower.  IGNORED.
Feb 19 20:46:05 systemd-fsck[621]: FEDORA_ROOT: Inode 10516007 extent tree (at level 1) could be narrower.  IGNORED.
Feb 19 20:46:05 systemd-fsck[621]: FEDORA_ROOT: Inode 10625471 extent tree (at level 1) could be shorter.  IGNORED.
Feb 19 20:46:05 systemd-fsck[621]: FEDORA_ROOT: Inode 10625523 extent tree (at level 1) could be shorter.  IGNORED.
Feb 19 20:46:05 systemd-fsck[621]: FEDORA_ROOT: Inode 10625692 extent tree (at level 1) could be shorter.  IGNORED.
Feb 19 20:46:21 systemd-fsck[621]: FEDORA_ROOT: 1850192/11526144 files (0.3% non-contiguous), 16292812/46080000 blocks
Feb 19 20:46:22 systemd[1]: Finished systemd-fsck-root.service - File System Check on /dev/disk/by-uuid/906141b3-5cb6-456b-866e-26f74de391ab.
Feb 19 19:46:23 systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice /system/systemd-fsck.
Feb 19 19:46:23 systemd[1]: Starting systemd-fsck@dev-disk-by\x2duuid-1016\x2d985E.service - File System Check on /dev/disk/by-uuid/1016-985E...
Feb 19 19:46:24 systemd-fsck[904]: fsck.fat 4.2 (2021-01-31)
Feb 19 19:46:24 systemd-fsck[904]: /dev/nvme0n1p1: 32 files, 77508/523262 clusters
Feb 19 19:46:24 systemd[1]: Finished systemd-fsck@dev-disk-by\x2duuid-1016\x2d985E.service - File System Check on /dev/disk/by-uuid/1016-985E.
Feb 19 19:46:24 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-fsck@dev-disk-by\x2duuid-1016\x2d985E comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

it’s annoying as it takes time i do not want my machine to give.

2

I think that means that the system did not shutdown for the reboot cleanly.
Does this happen on a normal reboot?

1 Like
3

no, only after the offline update…

these are the last lines immediately after the update und before shutting down. in the subsequent bootup root was fsck’ed.

Feb 19 19:45:25 audit[1046]: SOFTWARE_UPDATE pid=1046 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:rpm_t:s0 msg='op=update sw="dnf5-plugins-5.2.10.0-2.fc41.x86_64" sw_type=rpm key_enforce=0 gpg_res=1 root_dir="/" comm="dnf5" exe=2F7573722F62696E2F646E6635202864656C6574656429 hostname=? addr=? terminal=? res=success'
Feb 19 19:45:25 dnf5[1046]: [56/56] Removing libwbclient-2:4.21.3-5 100% |   1.0   B/s |   4.0   B |  00m02s
Feb 19 19:45:25 dnf5[1046]: Warning: skipped OpenPGP checks for 27 packages from repository: @stored_transaction
Feb 19 19:45:25 dnf5[1046]: Transaction complete! Cleaning up and rebooting...
Feb 19 19:45:25 systemd[1]: Reboot requested from client PID 1046 ('dnf5') (unit dnf5-offline-transaction.service)...
Feb 19 19:45:25 systemd[1]: Shutting down.
Feb 19 19:45:25 dnf5[1046]: Complete!
Feb 19 19:45:25 audit: BPF prog-id=58 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=55 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=57 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=56 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=53 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=52 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=54 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=38 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=37 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=59 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=61 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=60 op=UNLOAD
Feb 19 19:45:25 audit: BPF prog-id=28 op=UNLOAD
Feb 19 19:45:25 systemd[1]: Using hardware watchdog 'SP5100 TCO timer', version 0, device /dev/watchdog0
Feb 19 19:45:25 kernel: watchdog: watchdog0: watchdog did not stop!
Feb 19 19:45:25 systemd[1]: Watchdog running with a hardware timeout of 10min.
Feb 19 19:45:25 systemd-shutdown[1]: Using hardware watchdog 'SP5100 TCO timer', version 0, device /dev/watchdog0
Feb 19 19:45:25 systemd-shutdown[1]: Watchdog running with a hardware timeout of 10min.
Feb 19 19:45:25 systemd-shutdown[1]: Syncing filesystems and block devices.
Feb 19 19:45:25 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Feb 19 19:45:25 systemd-journald[748]: Received SIGTERM from PID 1 (systemd-shutdow).
Feb 19 19:45:25 bluetoothd[1044]: Terminating
Feb 19 19:45:25 alsactl[1043]: alsactl daemon stopped
Feb 19 19:45:25 dbus-broker[1054]: Dispatched 3688 messages @ 3(±14)μs / message.
Feb 19 19:45:25 bluetoothd[1044]: Disconnected from D-Bus. Exiting.
Feb 19 19:45:25 bluetoothd[1044]: Battery Provider Manager destroyed
Feb 19 19:45:25 bluetoothd[1044]: Stopping SDP server
Feb 19 19:45:25 bluetoothd[1044]: Exit
Feb 19 19:45:25 systemd-journald[748]: Journal stopped
4

That seems to be problem free.

I’m not sure what to suggest.

1 Like
5

I suggest executing a non-offline dnf update to determine if a fsck occurs on boot. If both non-offline and offline methods cause a fsck, I would investigate /etc/fstab.

The last digit in the /etc/fstab mount command determines if a fsck will occur on boot.
The recommended value for ext4 / is 1 which means fsck this disk before others on boot.
The recommended value for btrfs is 0 which means do not check on boot.

If you performed a “default” install, that value should be 0 unless it has been manually changed.

1 Like
6

just tested it. the fsck only happens after an offline update. when i do a “normal” update everything works fine.

the mount-options of the root partition in /etc/fstab are as follows:

/          ext4      defaults,noatime    1 1

anyways, i changed it to end with

0 1

because “dump” is obviously legacy.

but i don’t get why there isn’a a fsck always performed, when pass is set to “1”.

currently pass is set to 1 but a fsck only happens after offline-updates. can you please explain that to me?

7

First some info on how to enable and also cancel forcing a file system check on a partition on reboot:

To force file system check on a partition, you must first change
fsck’s PASS value in /etc/fstab to value 2.

Force fsck on each reboot:
sudo tune2fs -c 1 /dev/X

Force fsck on every tenth reboot:
sudo tune2fs -c 10 /dev/X

To disable fsck on all reboots execute either of the following:
sudo tune2fs -c -1 /dev/X
sudo tune2fs -c -0 /dev/X

Example fstab mount command where this has been applied:
UUID=1693c57b-4893-48ef-a1cf-dc20c4fa59d2 / ext4 defaults 0 2

You might try changing the PASS value from 1 to 2. Then execute one the commands above to disable file system checking before executing an offline update.

If this corrects the problem, please file a Bugzilla bug report and include steps to both reproduce and fix the problem.

1 Like
8

so i tried setting the pass value to 0 and yet a fsck is conducted during the reboot. why is that?

nowadays my system even fsck’s on reboot when the prior shutdown was unclean, like a poweroff. in the past my system hasn’t done this.

9

You can control the interval ( number of boots or disabled) before a fsck by following the directions in my prior post. If you have set the interval to disabled and the check happens during and offline update but not during a normal update, then it would be appropriate to file a Bugzilla bug report.