22

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
wjandrea
  • 14,504
s3lph
  • 14,644
  • 12
  • 60
  • 83

4 Answers4

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
Braiam
  • 69,112
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.

Joseph Santaniello
  • 306
  • 1
  • 8
0

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.

alexei
  • 427
  • 1
  • 3
  • 11
-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.

Vivek Ji
  • 187