My Ubuntu is running fsck on every bootup

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

Solution 1:

/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. [email protected] 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

Solution 2:

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.