[SOLVED] Question about file system checks

[hedgehoggy]

1) If Ubuntu automatically runs fsck every 30 boots, is the same true for Mint? And if yes, does it prompt you to fix errors or does it do so automatically?

2) When is it otherwise appropriate to initate a file system check? Will the system tell you?

3) Attempting to do a check from the grub menu, I got the following error message:

Code: Select all

Continuing will remount your / filesystem in read/write mode and mount any other filesystem defined in /etc/fstab. Do you wish to continue?
<Yes>
/lib/recovery-mode/recovery-menu: line 80: /etc/default/rcS: No such file or directory
fsck from util-linux 2.34
/dev/mapper/vgmint-root is mounted
e2fsck: Cannot continue, aborting.

What gives?

Also, just found this: viewtopic.php?t=282317

Does installing smartmontools, gsmartcontrol, & smart-notifier (actually just gsmartcontrol) also apply to SSDs?

[spamegg]

1. I haven't heard of this. Where did you hear this? Can you share links/sources? In my experience this seems to be false, because I would regularly get the BusyBox prompt because of piled up file system errors.

2. Many people have been having file system error issues in the last 7-8 months or so, I believe there is a bug in the kernel that happens for some people, some of the time. Usually it takes 1-2 weeks to become unable to boot and get the BusyBox prompt.

I used to have the following in my GRUB configuration file /etc/default/grub which ran fsck automatically and fix all errors automatically (only on the boot partition, not others) EVERY BOOT:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash fsck.mode=force fsck.repair=yes"

Recently I found this to be really overkill, so I opted for tune2fs: assuming your boot is on /dev/sda1

Code: Select all

sudo tune2fs -c 5 /dev/sda1

will run e2fsck EVERY 5 MOUNTS, whereas

Code: Select all

sudo tune2fs -i 5 /dev/sda1

will run e2fsck EVERY 5 DAYS. That's what I'm using now.

You'll have to decide when/how it is appropriate to run. This is a paragraph from man tune2fs:

Mount-count-dependent checking is disabled by default to avoid unanticipated long reboots while e2fsck does
its work. However, you may wish to consider the consequences of disabling mount-count-dependent checking
entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking
the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will
never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will
still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.

See also the -i option for time-dependent checking.

3. I never ran fsck or e2fsck directly from the GRUB command line, as I am not familiar with its syntax. I would hold Shift, go to Advanced Options/Recovery Mode/Drop to root shell and run fsck from the normal command line.

Hope this helps.

[Jo-con-Ël]

First you need to consider when you are taking about system partitions (auto-mounted on booting because they are included in /etc/fstab) and other partitions you only mount as desired (when browsing, by example).

1-2.If talking about system partitions, they are checked (it is not a full filesystem check) on every boot unless you tell not to do it changing pass # (fsck order) in /etc/fstab. Depending on checking filesystem state result will try to repair automatically if needed, but it also depends on damage. If filesystem can not be repaired successfully will prompt a busybox and drops in initramfs shell where you can see details of the problem and how to solve after writing exit

With other partitions or system partitions if pass # is set to 0 (i.e. to do not check on automounting what is not recommended), last checking date is take into account when mounting. If it is equal or superior 30 days, Ext.4 system partition would be checked and repaired. That is theory.

As per following vanadium post, looks like it has changed and now ext 4 fileystem in not checked depending on last check date or mount-count as it is disable by default if using journaling and only being full checked if it is needed ,i.e. if filesystem state is marked as unclean in the journal (after power outage or hard shutdown, or if getting full and find dificults on reallocating blocks to avoid data corruption it is marked for checking in next reboot).

In case of no system partitions you will be warned when mounting.

You can tune that checking frequency and other paramenters in ext fileystem (see man tune2fs)

3.- Those errors are clear enough. You will need to check/repair in other way. You can try booting recovery option in GRUB menu>Advanced option or form an external media if needed.

1. I haven't heard of this. Where did you hear this? Can you share links/sources? In my experience this seems to be false, because I would regularly get the BusyBox prompt because of piled up file system errors.

See here, by example. I think OP is mixing checking/repairing system partitons on booting with other partitions checking on mounting.

(edited)

[vanadium]

To check a file system, it cannot be in use. From the recovery menu in Grub, you can select the option "fsck" to check all file systems: that choice will automatically unmount your root partition (which is mounted read-only at that stage) and perform the check.

With respect to automatic file system check, check your current settings in the output of

Code: Select all

sudo tune2fs /dev/<your root partition> -l

These lines are important here:

Code: Select all

Last checked:             Mon Jul 19 14:28:04 2021
Mount count:              382
Maximum mount count:      -1

This root file system has not been checked for the last several months. Full file system checking actually is disabled: Maximum mount count is set to -1.

Apparently, the current configuration with ext4 is to never check the partition if the file system is marked as clean in the journal. In older versions of Mint, the system was configured to deep-check a root file system after every 30 mounts or 30 days.

[Jo-con-Ël]

Apparently, the current configuration with ext4 is to never check the partition if the file system is marked as clean in the journal. In older versions of Mint, the system was configured to deep-check a root file system after every 30 mounts or 30 days.

Thanks you for this clarification.

In any case I think the problem is not the frequency i.e. how often it is checked, but how often it is needed to be repaired, to find the reason and avoid as possible if you are interesting on keep your data safe.

[hedgehoggy]

Apologies for disappearing for so long (and especially for being so dense), but I'm really having a hard time with this--something that seems like it should be relatively straightforward. For me this all started after going through Pjotr's "40 Tips and Tweaks for Linux Mint" and arrivng at Set an automatic periodic file system check.

I don't even know if this is something I need to worry about in the first place--I'm not having any problems--but it seemed like a good idea to set it up if the system wasn't already checking itself. My partitions seem to have different names, possibly because I'm using a "mint only" setup with full disk encryption, so that's part of the confusion maybe. Also, when I try to check the system from grub, I get only error messages, some of which seem to suggest (if I remember right) that it couldn't do the check because partitions were already mounted or something like that. On gparted, the "check" option is greyed out for each of the partitions and clicking on "unmount" or "deactivate" seems like a really bad idea since I don't know what I'm doing.

If this is something that would be a good idea to set up, ideally I would get fsck/whatever to check the filesystem on shutdown every x times rather than at startup. I've looked and looked to see how often I should check the file system with linux mint on an SSD, a "best practices in the absence of any obvious problems" sort of thing but I haven't found anything concrete. Help!

---EDIT---
This is the error message I got when trying to do fsck from grub:

Press Enter for maintenance
(or press Control-D to continue):
root@lt-x1c7:~# fsck
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/mapper/vgmint-root is mounted.
e2fsck: Cannot continue, aborting

[vanadium]

As explained before, checking the root file system and other file systems mounted at start up is taken care off by systemd. No need to worry there.

[hedgehoggy]

Ok, sorry, I guess I missed that part, thanks!