Bug 55001 - Boot fails (locks during dosfsck) on Vaio C1 with Windows ME
Boot fails (locks during dosfsck) on Vaio C1 with Windows ME
Product: Red Hat Linux
Classification: Retired
Component: dosfstools (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Matt Wilson
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-10-24 00:44 EDT by Need Real Name
Modified: 2007-04-18 12:37 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-26 08:18:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-10-24 00:44:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012

Description of problem:
Boot fails on enigma when run on a Sony Vaio C1-VN with a Windows ME
partition during the dosfsck. Removing the filesystem from fstab allows the
boot to complete normally. Mounting the filesystem after boot works normally.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot system as above with 2G windows me partition
2. See system lock up!

Actual Results:  System is frozen and does not boot for at least 5 minutes,
maybe longer but I could not wait!

Expected Results:  dosfsck should check and complete. If dosfsck is not
capable of handling windows me filesystems it should not run.

Additional info:

Sony Vaio C1-VN
Crusoe 600MHz
12Gb Disk with 2G windows me partition
kernel 2.4.7-10 and 2.4.9-7 give the same results.
Comment 1 fdavid 2001-10-24 17:53:37 EDT
Same problem exists on a Toshiba Satellite 3000-S353.
If the vfat partition is checked during boot, the init-scripts fail and hang.
The kernel
is however still responsive (Alt+SysRq works)
Comment 2 Dan Anderson 2001-10-30 02:48:29 EST
I solved the problem with RedHat 7.2 hanging after upgrading and rebooting.

The problem occurs if you have a FAT32 filesystem in /etc/fstab.
This occurs even if it's not mounted at boot time or if the fsck field is "0"!

The symptom is you see this message during the boot up and the system hangs:
Warning: FAT32 support is still ALPHA

This message is from /sbin/fsck.vfat for RedHat 7.2 (dosfstools-2.7-1)
dosfstools-2.2-8 (for RedHat 7.1) doesn't have fsck.vfat.

Workarounds (do one of the following):
1. downgrade to dosfstools-2.2-8 from RH 7.1 (not recommended)
2. mv /sbin/fsck.vfat /sbin/fsck.vfat.broken; cp -p /bin/true /sbin/fsck.vfat
3. remove all DOS (FAT32) filesystems from /etc/fstab (not recommended)

Note to RedHat:
Comment 3 Dan Anderson 2001-10-30 02:50:34 EST
This happens with me, with Windows 2000 Professional.
The problem is RedHat Linux 7.2 has /sbin/fsck.vfat (dosfstools-2.7-1) and
RedHat Linux 7.1 does NOT have /sbin/fsck.vfat (dosfstools-2.2-8).
If you run fsck.vfat on a FAT32 filesystem, the command "hangs."

Workarounds (try one of the following):
1. mv /sbin/fsck.vfat /sbin/fsck.vfat.nogood; cp -p /bin/true /sbin/fsck.vfat
   I recommend this option.
2. Remove package dosfstools 2.7-1.  Install the dosfstools from RedHat 7.1:
       rpm -e dosfstools; rpm -Uvh dosfstools-2.2-8.i386.rpm

3. Remove any DOS filesystem from /etc/fstab. This is true even if it's
not automatically mounted at boot time or if the "fsck" column is "0"!
This option is the least desirable.

I found these solutions through hard work and would like to share so others
can avoid some misery when upgrading to RedHat 7.2.
After I found my workaround, someone else also found the same workaround. See

Comment 4 kenneth_porter 2001-11-04 10:13:05 EST
Confirmed. (Thank god for Google Groups!)

I worked around this by booting in single-user mode (add -s to kernel line in
grub) and then renaming /sbin/fsck.vfat to hide it. I did NOT symlink /bin/true
to that name, though. Is that going to cause me problems?
Comment 5 kenneth_porter 2001-11-04 10:38:41 EST
Dan, I tested the fstab fsck disable feature and it appears to work for me.

I changed the last two fields on my vfat partitions from "1 1" to "1 0", and
renamed fsck.vfat back to make it visible again. I then rebooted and the
"checking filesystems" process ran to completion with no message about FAT32
being alpha.
Comment 6 Dan Anderson 2001-11-04 19:48:04 EST
OK--partly my mistake.
I assumed the RedHat linux /etc/fstab was the same format as Solaris /etc/vfstab.
It WAS requesting a fsck at boot after all.
So, the problem isn't as bad as I thought.

HOWEVER, I think /sbin/fsck.vfat should NOT be added to package dosfstools
if using it only causes the system to hang and if it apparently doesn't work
and, according to the warning, it not even a production-quality program yet
(i.e., stops on the "Warning: FAT32 support is still ALPHA" message).

At the very list, why not stop /sbin/fsck.vfat from hanging and return a
non-zero status instead?

Comment 7 Ulrik Petersen 2002-03-05 18:07:19 EST
To quit dosfsck just press Ctrl-C.  This lets the boot procedure proceed.
Comment 8 galaxenspresident 2002-03-26 08:18:52 EST
*Support Forums> Red Hat Linux Installation and Configuration Support Forum> 
The search "Fat32 is alpha" gives the folowing posted message: 

>Luis Moscovich (luchogm) - 12:10am Jan 18, 2002 EDT (2.) 
>  I had this problem (!Warning: FAT32 support is still ALPHA) myself. The
problem is a bug in >fsck.vfat in the dosfstools package which enters an
infinite loop when checking a vfat partition with >a volume label present. In
order to solve it without disabling vfat file system checking on boot there >are
basically 2 options: 1) Boot to windows and remove the volume label on the fat32
partition you
>  want linux to mount, or 2) Upgrade dosfstools to version 2.8 (oh 7.2 install
version 2.7 dated Feb >14, 2001). Version 2.8 (dated Feb 28, 2001) fixed this
bug. The sources can be obtained from
>  ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools. Hope this helps, Luis 

RPM's for the version 2.8 is available for Mandrake, PLD and Rawhide
distributions. Let's hope it shows up as a fix in the Redhat errata pretty soon
as well since v2.8 seems to have been around a while now.
Comment 9 Matt Wilson 2002-03-26 11:15:43 EST
2.8 will be included in the next release.

Note You need to log in before you can comment on or make changes to this bug.