Mageia forum

I ask because in the dim and distant past when I used Windows 95 I had a line in the autoexec.bat that ran chdsk on switch off.

On what filesystem type (ext4, fat32, ntfs ...) do you want to run a check?

In general you can run fsck on a mounted filesystem in read-only mode but it will not produce reliable results.

Then I suppose a tool that runs in KDE, or any GUI that does produce good results, I do remember repairing files on a M2 Netbook with fsck a few years ago. But now command line work is getting harder and harder. Unless I could slow the keyboard repeat right down, the fs is journalized, 3fs I think.

You could install gparted. I know you can check filesystems from the GUI but I don't know if you can check a mounted fs.

doktor5000 wrote:In general you can run fsck on a mounted filesystem in read-only mode but it will not produce reliable results.

But then, gparted is usually used as a live boot media ...

True, but it's also available as a seperate installable app

As I'm running Mag5 now, it checks a disk on boot (after every 25 bootups etc ) with a very annoying delay and no message on the splash screen although of course progression indicated on the command-line interface accessed by ESC.
If a disk is so checked now and then with the Gparted app, will this bootup check stop? Is a flag "ok" set somewhere?

Actually that is not related if you do an fsck or not, but by the default setting for the number of times when that filesystem has been mounted.

You should read the tune2fs manpage:

Code: Select all

       -c max-mount-counts
              Adjust  the  number  of  mounts after which the filesystem will be checked by e2fsck(8).  If max-mount-counts is 0 or -1, the number of times the filesystem is mounted will be
              disregarded by e2fsck(8) and the kernel.

              Staggering the mount-counts at which filesystems are forcibly checked will avoid all filesystems being checked at one time when using journaled filesystems.

              You should strongly 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 nor‐
              mally 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.

This applies at least to all ext* filesystems. But you didn't mention which filesystem you use?