[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Skipping fsck during boot with systemd?

On 12/11/2014 03:37 PM, Charlie wrote:
On Thu, 11 Dec 2014 12:23:10 +0200 Andrei POPESCU sent:


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

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

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,

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

Reply to: