On 12/11/2014 03:37 PM, Charlie wrote:
On Thu, 11 Dec 2014 12:23:10 +0200 Andrei POPESCU sent:
<snip>
The root of my sid install was created before that, so I was still
getting the periodic check for it. The other ext4 filesystems were
newer, so weren't checked (and I didn't even notice it).
I've just disabled the automatic check on the root partition as well,
but I'm considering how to implement a forced fsck every now and
then, including an xfs partition, which wouldn't be checked at boot
anyway.
I have to admit that I noticed it, but was made an ass off, because I
assumed it was happening in the background. Not realising it always
started before the boot because it couldn't fsck while the machine was
running.
I thought that might have been what allowed systemd to boot faster?
If you find a way "to implement a forced fsck every now and then could
you please post it here. As I would be very pleased to be able to do
that now realising it is no longer happening at all.
Being and "ordinary" user I have no idea where to look or even start.
Thank you,
Charlie
Some of the messages in this thread are an exchange between myself and
Andrei Popescu. Andrei came up with a perfectly easy solution which I
have tested and found to work.
It involves an edit (as root) of /etc/rc.local to add a single line.
That line invokes the tune2fs utility to set a parameter called maximum
mount count to 0 during the boot process. That keeps fsck from being
invoked.
For a system which boots from /boot in /dev/sda1 I used:
tune2fs -c 0 /dev/sda1
as the line added to rc.local.
When I want to manually run fsck on that partition I use:
# tune2fs -c 1 /dev/sda1
That sets maximum mount count to 1, which means that fsck will be run on
/dev/sda1 the next time the system is booted. This strategy means that,
following the file system check, rc.local will again use tune2fs to set
the maximum mount count back to 0 so that fsck won't run on the
subsequent reboot.
And Bob's your uncle!
Yours truly,
another ordinary user -- JP
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548a0de7.8060...@comcast.net
