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 given. 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 is intact. Version-Release number of selected component (if applicable): How reproducible: Always 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 attempts. 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 perfeclty. Additional info: 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 :/
Hi boy, Have a look on this one : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50874 It seems you need 0 0 at the end of the line instead of 1 1 in your fstab for windows partitions. Have fun, Jean-Yves LENHOF
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...