run fsck manually...AGAIN....
-
If the action , or no action as in this case, speaks louder then marketing superlatives / words... My fantastic, best-est in its class Linux OS periodically and automatically runs "fsck" and "fixes" faulty file(s) on boot... Then with same consistency - it asks for "fsck" to be run AGAIN , manually... It then asks if I really want the faults to get fixed...each and EVERY problem detected ! I am just curios why this has been going on for last four or five "releases"... why "fsck" does not do the job in FIRST , automatic , run... what is the "coder" reasoning for asking me to run the manual "fsck" AND NOT wanting to get the problem fixed?? AHA answering (NO) to questions posted...?? perhaps asking ONCE (yes, fix it all) and get it all fixed is naive..on my part... however, if "automatic fsck " does not fix the problem - how does "manual fsck" fixes it , later ...? PS plebe do not bother to reply if the answer / comment is "... rant ,,, who cares ..."
-
If the action , or no action as in this case, speaks louder then marketing superlatives / words... My fantastic, best-est in its class Linux OS periodically and automatically runs "fsck" and "fixes" faulty file(s) on boot... Then with same consistency - it asks for "fsck" to be run AGAIN , manually... It then asks if I really want the faults to get fixed...each and EVERY problem detected ! I am just curios why this has been going on for last four or five "releases"... why "fsck" does not do the job in FIRST , automatic , run... what is the "coder" reasoning for asking me to run the manual "fsck" AND NOT wanting to get the problem fixed?? AHA answering (NO) to questions posted...?? perhaps asking ONCE (yes, fix it all) and get it all fixed is naive..on my part... however, if "automatic fsck " does not fix the problem - how does "manual fsck" fixes it , later ...? PS plebe do not bother to reply if the answer / comment is "... rant ,,, who cares ..."
Having to fsck continually is a symptom of either failing hardware (disk or disk controller on MoBO), or poor admin practices. Older file systems (eg. ext[2-4]) do have filesystem attributes that tell the OS to run fsck on reboot every n mounts or if fsck has not been run for n days. If you are using and ext based file system, then you can check and modify those values with
dumpe2fsandtune2fs. You're going to hate me for saying so, but check the man pages for those commands to see how they work. I'm don't know if xfs or btrfs have similar attributes. You can check what filesystems are in use by examining /etc/fstab e.g:# cat /etc/fstab
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
LABEL=/u /u ext3 defaults 1 2
/dev/sda2 swap swap defaults 0 0If you have xfs or btrfs or other file system, then google for the filesystem type and maintenance. That should hopefully lead you to the correct incantations to manage the fs. I have many Linux systems under my care. My main day-to-day system is currently running Fedora-37, but I help manage various boxes all over the place running various CentOS flavors, and Raspberry PIs running Rasbian. There are only 2 cases that an fsck needs to be run manually. 1) there's disk corruption, likely due to hardware malfunction. 2) an improper shutdown - normally due to a power outage. If you're continually having to run fsck, then its almost certainly due to one of those 2 issues. If you do a normal shutdown (eg either
powerofforshutdown -has root) and wait for the system to power itself off, then you're almost certainly looking at failing hardware. See what smartctl (again RTFM!) can tell you, and try running some of the disk self tests. Good luck!Keep Calm and Carry On