FAT drive scanned at boot, triples startup time

[Donald Straney]

Binary package hint: ubiquity

First, I should mention that this is somewhere between a bug and a design decision, but it seems a lot more like a bug, so I apologize if I filed this in the wrong place.

The installer for Ubuntu 6.10 correctly detected all my internal drives and added commented-out entries to fstab for the non-root partitions. However, it set the "check on boot" field to 1 for my 33 GB FAT32 partition, and so when it booted it ran fsck on that partition, which added about 3 minutes to the boot time (I changed fstab so it wouldn't scan, and it booted in 1 minute), dropped to text mode during the scan, and filled the screen with lists of numbers - at first I thought it had crashed. Since FAT32 partitions usually take a very long time to scan compared to normal Linux filesystems like ext3 or reiserfs, I assume that the installer wasn't supposed to mark those to be checked every time at boot?

Again, I'm sorry if this is the wrong place to report this.

[Onno Benschop (onno-itmaze)]

Donald,

Thank you for your report. In order to assist with the resolution of your bug, can you please attach the output of this command:
 dosfsck -v -n <partition>

[Onno Benschop (onno-itmaze)]

Donald,

Thank you for that. Can you tell me which version of dosfstools you have installed? The command is:
 COLUMNS=132 dpkg -l dosfstools

Also, does this partition show any errors if it's checked under Windows?

[Donald Straney (burntfuse)]

The version's 2.11-2.1ubuntu1. When I checked the drive with chkdsk in Windows, it found at least one error on the drive. I guess my point isn't that there's a problem with FAT32 disk checking in Ubuntu, though - it's that the partition gets scanned at boot by default, which will take a long time for any decent-sized FAT partition even if there aren't any errors, and I assumed the installer was only supposed to set up fstab so only filesystems which can be checked very quickly (like ext3 or reiserfs) are scanned at boot.

[Onno Benschop (onno-itmaze)]

While I understand what you're saying, in fact there is a bug report for just that case -- changing the scanning methodology, bug #59293 and related to that bug #48806, I'm trying to make the behaviour of dosfstools predictable.

At the moment, your bug could be interpreted as a fstab issue and a duplicate of the above two bugs, but I'm curious to know what the error was that scandisk found.

What I'm trying to determine is if you've found another bug in dosfstools, or just unexpected behaviour we already know about.

[Donald Straney (burntfuse)]

Ah, ok, sorry for the misunderstanding (and the possible duplicate bug - I looked hard for any similar bugs before filing this one). Unfortunately, chkdsk didn't give any detailed information on the errors it found, and I wasn't able to find anything in logs or anywhere else it might have been stored.