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
  • 1
    fsck says it didn't run, that the volume was clean. – psusi Nov 28 '13 at 1:52
  • But the checking component has to run in order to say it is clean, doesn't it? – s3lph Nov 28 '13 at 16:39
up vote 25 down vote accepted
+50

/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
  • 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 1 '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 1 '13 at 15:27
  • I read that changing the last digit to 0 disables fsck on mount – s3lph Dec 1 '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 1 '13 at 15:38
  • 2
    There is a bug reported on launchpad: upstart bug #1504688 . It contains a possible solution in comment #17. – azurkin Jul 15 '16 at 20:49

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.

  • No it's definitely fsck. The Running /scripts/init-bottom ...done is printed at about 3s, the fsck-clean at about 30s. – s3lph Dec 4 '13 at 20:22
  • What type of filesystem are you using? – Joseph Santaniello Dec 5 '13 at 18:27
  • I am using EXT4 – s3lph Dec 5 '13 at 18:35
  • Is the pause before it prints "fsck von ..." or before "/dev/sda..."? – Joseph Santaniello Dec 5 '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: wiki.archlinux.org/index.php/Systemd#Automount – Joseph Santaniello Dec 5 '13 at 18:51

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.

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.

  • 1
    No, that means the value will be disreagrded by the kernel and e2fsck: 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 2 '16 at 16:13
  • My bad, will change post. – Vivek Ji Sep 3 '16 at 5:54

As others have posted the maximal mount count can default to -1 which means fsck is run on every boot which will naturally slow the boot process down.

Change the frequency of fsck to every 50 boots or every 30 days using:

$ sudo tune2fs -c 50 -i 1m /dev/sdc3

tune2fs 1.42.13 (17-May-2015)
Setting maximal mount count to 50
Setting interval between checks to 2592000 seconds

Assuming today is November 13, 2016, check when fsck will be next be run using:

$ sudo dumpe2fs -h /dev/sdc3 | grep Next

dumpe2fs 1.42.13 (17-May-2015)
Next check after:         Tue Dec 13 22:45:39 2016
  • This is not accurate. The man page for [tune2fs]( linux.die.net/man/8/tune2fs) states that zero check interval means disable ichecking on max count and -1 max mount count means disable checking on max count. And, setting these did not fix the issue on my system (which was due to bad clock -- not having an RTC). – alexei Jun 19 '17 at 4:52
  • @alexei I took out the reference to -1 thanks for pointing that out. – WinEunuuchs2Unix Jun 19 '17 at 22:58
  • FTR I reran these commands on a brand new Ubuntu 16.04.3 setup on October 31, 2017 and they still work as posted. Still new installations default to running fsck every boot. – WinEunuuchs2Unix Oct 31 '17 at 23:09

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.