sometimes my volumes need to fsck after I reboot with files in use?

afader · 2025-04-20 07:21:53

Sometimes my drives are unbootable when certain applications such as qbittorrent or transmission are working on a file and I reboot and it somehow does not quit. Is this an application bug? Some system configuration issue? Systemd config? Basically what happens is, I reboot and find that I cannot boot and it hangs on a disk mount. Then I can reboot into a rescue live usb, fsck the drives, and it works again. I tried adding a force fsck to my boot but sometimes I still need the live usb to fix it. Suggestions how I can either prevent the dirty reboots from happening or force the fsck to fix it on reboot?

mpan · 2025-04-20 07:46:17

Post the journal from a boot preceding problems: starting at the point you invoke shutdown, up to the very end. How do you peform the shutdown? What machine is that? What kernel version?

seth · 2025-04-20 08:05:27

The inconsisten filesystem indicates that the FS hasn't been properly closed, ie. you reboot with the power button?
Don't.

The shutdown/reboot iss supposed to terminate all processes, sync and close (unmount) all filesystems and only *then* cut power.

Caveats (but we lack details on your situation)
1. parallel windows and NTFS partitions, 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
2. overaggressive trimming, https://wiki.archlinux.org/title/Solid_state_drive#TRIM
3. drive internal caches and esp. USB disks (the disk writes from internal volative memory and loses power too early
4. btrfs, zfs and other experimental filesystems

fsck happens during boot anyway w/ default fstab setups, if you figure "oh, this somehow hangs, let me push the power button" you're aggravating the situation.

=> details and maybe a system journal covering reboots that lead to mount failures?

afader · 2025-04-20 08:48:43

Right now I am trying to increase the reboot timeout time.
Using latest vanilla arch kernel but problem has existed on and off for a while through several kernel upgrades, but maybe just started happening again more lately.
Machine has Nvme, several ssds and rotational drives on sata, asus motherboard and intel chip from a few years ago. Rebooting by opening a terminal and typing "reboot" usually but maybe if the system crashes and is unresponsive (uncommonly) I will use the power button.
Next time I experience the problem I will capture a journal log.
No dual-boot with windows and ntfs anymore, just a bunch of ext4 and efi esp on the nvme. I guess overaggressive trimming could be the issue? How can I check that? I have some trim timer perhaps. No btrfs or zfs but I have had overlayfs.

seth · 2025-04-20 15:07:52

Periodic trimming should™ be fine, tbs, check "mount" and that nothing there says "discard".

Avoid using the power button at all costs, systemd has a 90s timeout - get some coffee.
If coffee doesn't help, frenetically press ctrl+alt+del or resort to the https://wiki.archlinux.org/title/Keyboa … el_(SysRq)

have had overlayfs

While this was an active problem or "have had for a while somewhen during covid because I was bored to death"?

You can access older journals, eg. "sudo journalctl -b -5" for five boots ago.

Arch Linux

#1 2025-04-20 07:21:53

sometimes my volumes need to fsck after I reboot with files in use?

#2 2025-04-20 07:46:17

Re: sometimes my volumes need to fsck after I reboot with files in use?

#3 2025-04-20 08:05:27

Re: sometimes my volumes need to fsck after I reboot with files in use?

#4 2025-04-20 08:48:43

Re: sometimes my volumes need to fsck after I reboot with files in use?

#5 2025-04-20 15:07:52

Re: sometimes my volumes need to fsck after I reboot with files in use?

Board footer