Red Hat Bugzilla – Bug 52034
Boot hangs on mounting VFAT parts
Last modified: 2007-04-18 12:36:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010725
Description of problem:
Adding and mounting FAT32 drives (as vfat) data is accessable as usual,
however upon a reboot at external drive mount time a warning is given that
FAT32 is in ALPHA code, and then hangs. Nothing past a one line warning is
The drives are:
/dev/hda6 /mnt/dos/e vfat exec,dev,suid,rw 1 1
/dev/hda5 /mnt/dos/d vfat exec,dev,suid,rw 1 1
/dev/hda2 /mnt/dos/c vfat exec,dev,suid,rw 1 1
In order to regain access to my system I needed to use a CD and boot to
rescue mode, and comment out those 3 drives from the /etc/fstab
For some reason after a forced hard reset my windows partitions would not
boot from lilo anymore, although according to norton disk doctor all data
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Installed linuxconf via Redhat Network
2. Added the 3 dos partitions listed previously under the Filesystems/Add
Local Drive, mount & accept. Quit linux conf.
3. Check systems loaded under /mnt/dos/X and copied some files from them to
another computer on the network (my redhat 7.1 gateway)
4. Rebooted the pc.
Actual Results: After entering the section of boot with the [ ok ]
confirmations, daemon loading etc (sorry I dont know the term for that
part) it comes to the loading of the VFAT drives from fstab, gives a breif
warning of FAT32 being in ALPHA, and hangs immediatly. This has happend
every boot untill I commented out the drives in rescue mode, at least 6
I have not tryed again since commenting out, sorry for this but so far I
cant boot my windows drives anymore, and although they are not critical, I
would prefur not to loose any data from them. So far I have not managed to
force windows to boot again but am still trying.
Expected Results: As per Redhat 7.0/7.1/SuSE 7.2/Slackware 7.0/Progeny
Debian RC1 of wich all have existed on the same disk previously and where
Roswell is now, have mounted these drives on boot with not a single problem.
Infact mounting the drives AFTER boot manualy or thru linuxconf works
I belive, although cannot be certen, the system atempted to "check" my
FAT32 disks as if they were EXT2/EXT3 (I run EXT3 on all my linux
partitions under Roswell). Unfortunatly I cannot verify this untill I can
recreate the issue.
I have marked this as high on the basis my Windows disk no longer boots,
and so far does not want to be fixed. (perhaps thats a blessing tho? ;)
using roswell, i have no problems at mouting vfat at boottime: here are my fstab
lines, could you try them out?:
/dev/sda1 /mnt/c vfat rw,async,exec,auto,nouser,uid=500 0 0
/dev/sda5 /mnt/d vfat defaults,uid=500,auto 0 0
/dev/sdb5 /mnt/e vfat defaults,uid=500,auto 0 0
you will maybe need to change the uid, of course
maybe an important part?: i'm using a home-compiled kernel
but in fact, i suspect some options to let it hang; the trick would be to find
out which ones. No time now to check it now :/
Have a look on this one :
It seems you need 0 0 at the end of the line instead of 1 1 in your fstab for
Yes, 50874 is actually the exact same thing.
*** This bug has been marked as a duplicate of 50874 ***
I need to make an amendment to the bug, the windows booting problem is NOT
related, I am sorry I did not realise this before. However the halting on boot
still is true, it happens at the stage "Checking Filesystems" and halts,
although the pc it's self does not appear locked after a few minuts nothing has
happend still. Again I ended up doing a manual fstab edit via rescue mode.
This time however no FAT32 warning was given before the halt..
The 0 0 part was correct, appolagies for wasting time on this, when I searched
oridionaly I did not find any other bugs with "boot crash fat32"
More of a linuxconf bug perhaps...