fsck run during boot fails to scan second hard drive

[S. Christian Collins]

Binary package hint: e2fsprogs

** Bug Description **
First off, my problem seems most similar to the one reported in bug #412809, but that bug has been marked invalid due to the lack of follow-up from the original poster.

Here's what happens: I have two SATA drives in my system, the first (sda) with multiple partitions, the second (sdb) with a single, 500GB partition (sdb1, with an fstab entry to mount to /home/chris/Storage). When fsck decides to scan any of the partitions on sda during bootup, it never has a problem, but when it scans sdb1, the scan sits at 0% for probably 10-15 seconds, and then the system continues to boot into KDE. The disk scan apparently never completes, and after the system is booted, I find sdb1 is not mounted to /home/chris/Storage as it should be.

I have found that if I wait long enough (not sure how long, but at least some minutes) the drive will eventually show up mounted. My guess from this discovery is that the filesystem check must have continued in the background while the system proceeded to boot. The long time before the drive is mounted is probably due to its large size (500 GB).

Here is the line for sdb1 in my fstab file:
UUID=aaf83cd3-50ae-4245-91bd-2dd474baecc8 /home/chris/Storage ext3 noatime 0 2

If I run blkid prior to the sdb1 scanning weirdness, I get:
/dev/sdb1: LABEL="Storage" UUID="aaf83cd3-50ae-4245-91bd-2dd474baecc8" TYPE="ext3"

But if I run blkid after the scanning weirdness, I get:
/dev/sdb1: LABEL="Storage" UUID="aaf83cd3-50ae-4245-91bd-2dd474baecc8" SEC_TYPE="ext2" TYPE="ext3"

** Expected Behavior **
I would expect the disk scan to complete prior to booting the system. The current behavior is very disconcerting to users who are left wondering what the heck happened to their files.

** Bug Reproduction **
I would imagine having a second SATA hard drive of large capacity (500GB or greater) set to a mount point in /etc/fstab running on (K)Ubuntu Karmic would probably be all you would need to trigger this bug. This bug did not happen on my system with Jaunty or earlier.

** My System **
Motherboard: MSI K9N SLI Platinum (nForce 570 SLI chipset)
CPU: AMD Athlon(tm) 64 Processor 4000+
RAM: 2GB DDR2
OS: Kubuntu 9.10 i386 (with KDE 4.3.3)
Linux Kernel: 2.6.31-9-rt

ProblemType: Bug
Architecture: i386
Date: Tue Nov 10 14:40:19 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Kubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
NonfreeKernelModules: nvidia
Package: e2fsprogs 1.41.9-1ubuntu3
ProcEnviron:
 LANGUAGE=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-9.152-rt
SourcePackage: e2fsprogs
Uname: Linux 2.6.31-9-rt i686
XsessionErrors:
 (polkit-gnome-authentication-agent-1:2386): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (huludesktop:2424): Gtk-CRITICAL **: gtk_style_detach: assertion `style->attach_count > 0' failed

[Scott James Remnant (Canonical) (canonical-scott)]

Add "bootwait" to the options in /etc/fstab for that mount point