My Ubuntu is running fsck on every bootup

Question

On every bootup it's the same:

/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks

Is it some kind of option Ubuntu uses to ensure filesystem consistency or is there something wrong with my HDD? fsck takes up to 30s while booting and so about triples the time needed otherwise.

Full output (partly in German):

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
fsck von util-linux 2.20.1
/dev/sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke
udevd[623]: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/45-libticables.rules:6

udevd[623]: invalid rule '/lib/udev/rules.d/45-libticables.rules:6'

 * Starting mDNS/DNS-SD daemon                                                 [ OK ]
 * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated                                                                   [ OK ]
 * Starting configure network device security                                  [ OK ]
 * Starting bluetooth daemon                                                   [ OK ]
 ####* Starting all other stuff

What version of Ubuntu are you running? Does your system shutdown cleanly? — ubfan1, Nov 27 '13 at 22:26
Raring x64 = 13.04 64bit. Shutdown runs cleanly as far as I can say (Where's the shutdown logfile?) — s3lph, Nov 27 '13 at 22:29
But the checking component has to run in order to say it is clean, doesn't it? — s3lph, Nov 28 '13 at 16:39

Braiam · Accepted Answer · 2016-07-15T23:15:35.647

28

/dev/sda1: clean, 908443/38690816 Files, 44176803/154733312 Blocks

The line producing that message is this:

/* Print the summary message when we're skipping a full check */
log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),

It skips the "full check" but just made sure that some fast test to the journal are clean and there isn't orphan inodes:

cat /var/log/boot.log 
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
/dev/sda1: clean, 260598/771552 files, 1684682/3080192 blocks
/dev/sdb10: recovering journal
/dev/sdb10: Clearing orphaned inode 142568 (uid=1000, gid=1000, mode=0100664, size=32768)
/dev/sdb10: Clearing orphaned inode 138527 (uid=1000, gid=1000, mode=0100600, size=9580)
/dev/sdb10: clean, 54957/991232 files, 3498365/3958006 blocks

This is normal and expected. If it was a real thorough check it would take much more time but it usually takes a second or less. Systemd systemd-fsck(8) manual page has the conditions where a full check is triggered:

systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.

These services are started at boot if passno in /etc/fstab for the file system is set to a value greater than zero. The file system check for root is performed before the other file systems. Other file systems may be checked in parallel, except when they are on the same rotating disk.

systemd-fsck does not know any details about specific filesystems, and simply executes file system checkers specific to each filesystem type (/sbin/fsck.*). This helper will decide if the filesystem should actually be checked based on the time since last check, number of mounts, unclean unmount, etc.

You can simply check that the tests took next to nothing to run (if you use systemd):

sudo systemd-analyze blame | grep fsck
          1.608s systemd-fsck@dev-disk-by\x2duuid-408535fe\x2d28e6\x2d4d82\x2dbb59\x2d9810ead089a3.service
            87ms systemd-fsck@dev-mapper-vlhome\x2dlvhome.service

edited Jul 15 '16 at 23:15

answered Dec 01 '13 at 14:55

Braiam

67,791
32
179
269

An answer to the q at your link says you can control the behavior by modifying /etc/fstab. Is it only possible to set 0 or 1 or can I tell my system when to perform this "fast" test? – s3lph Dec 01 '13 at 15:14
@the_Seppi no, you can't deactivate the fsck in the fstab but the order, this other answer of mine explains it, just read it about the end of it. – Braiam Dec 01 '13 at 15:27
I read that changing the last digit to 0 disables fsck on mount – s3lph Dec 01 '13 at 15:29
@the_Seppi yeah, you are right, 1 and 2 determine the order to be checked but 0 or none says that it doesn't need. But then I have both values in 0 and still get the check. – Braiam Dec 01 '13 at 15:38
I tried setting 0. Now the fsck isnt appearing any more, but theres still a 25s pause. And its saying "recoverz required on ro filesystem". I just changed it back for this concerns me... – s3lph Dec 01 '13 at 16:19
@the_Seppi apparently then your system either is dirty/failling or you have the /forceck file in your root directory. I would boot as recovery mode, run fsck then remove the file if it exist. – Braiam Dec 01 '13 at 16:21
I can't boot into recovery for GRUB doesn't show up on hitting shift... Instead I created /forcefsck. On reboot it told me it was performing fsck. However, the recovery required still appears and both files in /var/log/fsck/ say "nochting logged yet" – s3lph Dec 01 '13 at 16:37
@the_Seppi as I said, my Debian always do that even in cold boot, so I presume Ubuntu is doing the same, but be aware that the test isn't complete/exaustive. – Braiam Dec 01 '13 at 20:04
2

There is a bug reported on launchpad: upstart bug #1504688 . It contains a possible solution in comment #17. – Tim Jul 15 '16 at 20:49
@azurkin there's no "bug", there's no "problem". The message is harmless and happens on most debian-based systems. – Braiam Jul 15 '16 at 21:02
@Braiam i know that it is not a bug. I called it a bug, only because it is reported on bugs.launchpad.net :) But I don't think that all ubuntu users must see such message on every boot after a splash screen. I found this question while searching for information about this message, because I didn't know if it was ok or not to see it. – Tim Jul 17 '16 at 08:17
@Braiam any excessive output while linux was told "quiet splash" should be considered a bug. Checking FS state b4 booting is for greater good, yes. Displaying meaningless "everything is OK" message, interrupting the splash screen is NOT! – mekkanizer Jul 03 '17 at 11:26
@mekkanizer is not "excessive output", not by any metric. Everything is doing exactly as it should. – Braiam Jul 03 '17 at 12:58

score 1 · Answer 2 · answered Dec 04 '13 at 11:33

1

Are you sure it is fsck that is taking 30s and not just that the next console message relating to udevd takes 30 seconds? In other words, maybe the udevd is taking 30 seconds to timeout working on the libticables thing before showing a console message?

Try removing (or moving someplace else temporarily)

/lib/udev/rules.d/45-libticables.rules

and see if that helps.

answered Dec 04 '13 at 11:33

Joseph Santaniello

306
1
8

No it's definitely fsck. The Running /scripts/init-bottom ...done is printed at about 3s, the fsck-clean at about 30s. – s3lph Dec 04 '13 at 20:22
What type of filesystem are you using? – Joseph Santaniello Dec 05 '13 at 18:27
I am using EXT4 – s3lph Dec 05 '13 at 18:35
Is the pause before it prints "fsck von ..." or before "/dev/sda..."? – Joseph Santaniello Dec 05 '13 at 18:45
Where are you mounting /dev/sda1? You might try adding: noauto,x-systemd.automount to the fstab options if it's /home or something. So the system will skip mounting until it is acessed as per: https://wiki.archlinux.org/index.php/Systemd#Automount – Joseph Santaniello Dec 05 '13 at 18:51
/dev/sda1 is the system partition mounted at / – s3lph Dec 07 '13 at 11:32

score 0 · Answer 3 · answered Jun 19 '17 at 05:00

This fsck on every boot happened to me due to bad clock. It appears that systemd-fsck@ runs before systemd-timesyncd, and without a battery-backed RTC, the system time is wrong at the time fsck is run.

I confirmed that this is indeed what triggers the full check (instead of having fsck exit quickly), by disabling systemd-timesynd, setting clock to the pre-sync value found in journalctl, and running fsck. The e2fsck then proceeds to do a full check, once it detects that the last superblock write time is in the future:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Superblock last write time (Mon Jun 19 00:48:11 2017,
    now = Tue Jan 31 20:09:28 2017) is in the future.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
...

Note that, this trigger for the full check is unrelated to the other triggers of max mount count and time interval since last check, seen in dumpe2fs -h, mentioned in other answers here.

Note that, without setting the clock (that is, letting timesyncd sync it), fsck will not do a full check, but will exit quickly with a 'filesystem clean' message.

As a workaround, I disabled fsck in /etc/fstab by setting 'pass' field to 0. Eventually, I'll buy a battery backed RTC for this device.

Vivek Ji · Answer 4 · 2016-09-03T05:56:01.980

-1

My searches land me conclusion that Ubuntu default maximum mount count is set to -1. This means that fsck will never run on any boot regardless of number of mounts. You can check yours by command -

sudo dumpe2fs -h /dev/sda8 | grep -i 'mount count'

You can increase it on your requirement using tune2fs. A typical example is as follows -

sudo tune2fs -c 30 -i 1w /dev/sda8

Customise it on your accord.

edited Sep 03 '16 at 05:56

answered Aug 26 '16 at 12:01

Vivek Ji

187

1

No, that means the value will be disreagrded by the kernel and e2fsck: http://linux.die.net/man/8/tune2fs "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." – HappyCactus Sep 02 '16 at 16:13
My bad, will change post. – Vivek Ji Sep 03 '16 at 05:54

My Ubuntu is running fsck on every bootup

4 Answers4

Linked

Related