Hi Tim,
> > > The only thing I see that mentions fsck and my partitions is below
> > > but no mention of sda1:
> > >
> > > systemd-fsck[745]: /dev/sda2: clean, 254588/5185536 files,
> > > 7727002/20719616 blocks
> > > systemd[1]: Finished File System Check on
> > > /dev/disk/by-uuid/75b45da2-86b3-4574-96d8-3de84f1c4c49.
> > > systemd[1]: Mounting /home...
> > > kernel: EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts:
> > > (null)
> > > systemd[1]: Mounted /home.
> > > systemd-fsck[682]: /dev/sdb1: clean, 609505/61054976 files,
> > > 11916348/244190208 blocks
> > > systemd[1]: Finished File System Check on
> > > /dev/disk/by-uuid/04d578e3-78a4-474a-bac5-d048e001f565.
...
> I ran a fsck on the ext USB hard disk and it was a mess, error upon
> error. It was only at the start of August that I formatted the drive
> and ran smart on it and it reported as alright no issues found.
SMART is checking the veracity of the drive's media whereas fsck(8) can
suffer from those problems but also spot errors in the filesystem's data
which is reliably retrieved from the media.
> Strange thing was when I booted the laptop up after removing the entry
> in my fstab file it booted up without the File Check in progress
> message.
...
> For reference sdb1 was a 2.5" spinney disk??
...
> Fitted a new ext USB SDD drive and everything seems to be OK
I expect it's still happening but removing the last spinning rust means
it's all much quicker and so you either don't see it or, more likely, it
doesn't reach the threshold in time which makes it get displayed.
> So why was the file check saying that sda2 was clean
It was. :-)
> when obviously it was sdb1 that had the issues, there nothing in any
> of the logs to suggest there was anything untoward with sdb1.
Because a full filesystem check isn't being done at boot.
systemd-fsck@.service(8) extracts:
These services are started at boot if passno in /etc/fstab for the
file system is set to a value greater than zero.
systemd-fsck does not know any details about specific filesystems,
and simply executes file system checkers specific to each filesystem
type (/sbin/fsck.*). These checkers will decide if the filesystem
should actually be checked based on the time since last check,
number of mounts, unclean unmount, etc.
systemd-fsck understands these kernel command line parameters:
fsck.mode=
One of "auto", "force", "skip". Controls the mode of
operation. The default is "auto", and ensures that file
system checks are done when the file system checker deems
them necessary. "force" unconditionally results in full
file system checks. "skip" skips any file system checks.
So it starts fsck.ext4(8), probably with fsck.mode=auto.
For ext3 and ext4 filesystems that use a journal, if the system has
been shut down uncleanly without any errors, normally, after
replaying the committed transactions in the journal, the file system
should be marked as clean. Hence, for filesystems that use
journalling, e2fsck will normally replay the journal and exit,
unless its superblock indicates that further checking is required.
-f Force checking even if the file system seems clean.
It's worth performing forced fscks on filesystems periodically before
media errors compound any filesystem-metadata problem.
--
Cheers, Ralph.
--
Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00
Check to whom you are replying
Meetings, mailing list, IRC, ... http://dorset.lug.org.uk
New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
