PDA

View Full Version : mountmsdosfs: Bad Fat32 filesystem


pcbsdusr
12-26-2005, 09:25 PM
I first noticed this when shutting down my pc.

It usually appears if i forget to unmount the fat32 partition before shutting down.

This is what i getas soon as the gui shuts down:

Login: pbmap returned 0
mountmsdosfs: BAD FAT32 FILESYSTEM

the partition is ok and i can use it normally under pcbsd and windows.

while tracing another bug i was asked to run "dmesg | tail" from console.

when the fat32 drive is mounted, the result is:

CBSD# dmesg | tail
ad0: 190782MB <Seagate ST3200822AS 3.01> at ata2-master SATA150
ad1: 114473MB <Seagate ST3120026AS 3.18> at ata3-master SATA150
SMP: AP CPU #1 Launched!
cd0 at ata1 bus 0 target 0 lun 0
cd0: <HL-DT-ST DVDRAM GSA-4082B A201> Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ad0s3a
mountmsdosfs(): bad FAT32 filesystem
mountmsdosfs(): bad FAT32 filesystem
PCBSD#


Any ideas? i am sure this didnt use to happen before patch#3 which removed fstab.orig.

Thanks!

cheers,
Renato Flórido

Majorlag
12-26-2005, 09:39 PM
Sounds like you should run fsck_msdosfs on the partition. What I think is happening is that mount_msdfosfs is being called to unmount the partition since you didn't manually unmount it, and even though it is able to unmount the filesystem it notices that something is wrong. This doesn't prevent it from being usable, but an fsck should be run just in case.

Why this wouldn't happen with the old fstab.orig system is beyond me.

For kicks, before you run the fsck, try to mount the partition manually using mount -t msdosfs /dev/### /mnt/###. And see if that whines about anything.

pcbsdusr
12-27-2005, 12:43 AM
to run fsck_msdosfs i just eed to su, type it to console and press enter or do i need to add the device's path?

i unmounted the drive, mounted manually using your command for ad1s1, run fsck_msdosfs from console and run dmesg |tail after that.

if this is all i had to do, i have already done it and it is still giving me the same dmesg | tail output as before.

but i can assure you this was not hapening before patches#3/4.

Majorlag
12-27-2005, 01:13 AM
you have to run fsck_msdosfs on the dev, like "fsck_msdosfs /dev/ad1s1"

you may need to reboot, mount the fs, unmount it, and then run dmesg|tail to see any change.

pcbsdusr
12-27-2005, 01:32 PM
OK, done what you told me and seems to have been corrected. Here:

%su
Password:
PCBSD# mount -t msdosfs /dev/ad1s1 /mnt/ad1s1

PCBSD# fsck_msdosfs /dev/ad1s1
** /dev/ad1s1 (NO WRITE)
** Phase 1 - Read and Compare FATs
FAT starts with odd byte sequence (f8ffff0ffffffff7)
Correct? no
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
45 files, 1206336 free (1910404 clusters)

PCBSD# dmesg | tail
Timecounters tick every 1.000 msec
acd0: DVDR <HL-DT-ST DVDRAM GSA-4082B/A201> at ata1-master UDMA33
ad0: 190782MB <Seagate ST3200822AS 3.01> at ata2-master SATA150
ad1: 114473MB <Seagate ST3120026AS 3.18> at ata3-master SATA150
SMP: AP CPU #1 Launched!
cd0 at ata1 bus 0 target 0 lun 0
cd0: <HL-DT-ST DVDRAM GSA-4082B A201> Removable CD-ROM SCSI-0 device
cd0: 33.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ad0s3a
PCBSD#


no more errors. i have altered my stab to use msdosfs instead of auto on that partition as well. Could this have been the problem? I am sure i had no such problem before the fstab patches...

Majorlag
12-27-2005, 05:23 PM
Given the output of fsck_msdos I don't think the problem was related to patch 3. Just a little coincidental random filesystem corruption that (luckily) didn't hurt anything important.

pcbsdusr
12-27-2005, 07:10 PM
Looks like you are right. No errors now

But if you want i can reinstall from scratch, upgrade 1 patch at a time and check for these errors again.

Majorlag
12-27-2005, 07:32 PM
I am satisfied that there is no problem, but if you really really want to...

pcbsdusr
12-27-2005, 08:28 PM
No problem at all, pcbsd installs fast here (and runs faster) :D

i really want to get these errors ironed out so we can start getting productive.

give me five minutes to run the tests.

Update:
have run the tests in RC1 without patches. no problems so far

Update2:

have now run tests with all patches installed and no errors.

Update3:

The error has just returned when i rebooted. Something is wrong here... :(

Majorlag
12-28-2005, 12:48 AM
Ah ha. I think I know what is causing it now.
The error happens after you restart for the VERY FIRST time after patch 3 is installed, correct?
By any chance, is the filesystem mounted when you shut down? If so, I believe what is happening is that after fstab gets replaced by the new drive detection subsystem, the unmounting of all filesystems that takes place during shutdown might be getting confused and NOT unmounting that FS. Since its FAT32, this leads to some FS corruption. I'm not sure if it really warrents a patch though, since 1.0 final (I'm guessing) will use the new system exclusively... but it might cause problems for some people until then...

pcbsdusr
12-28-2005, 02:29 AM
that may be correct.

it happens as i shut down leaving the fat32 partition mounted.

i have tested it again and i find no errors now. I'll retest tomorrow and see what i find.

pcbsdusr
02-09-2006, 09:23 PM
I have installed RC2 and i still have this problem if i shutdown leaving the fat32 drive mounted.

I dont have any problems if the fstab has msdosfs instead of auto.

have you figured a way to get this working Majorlag?

we need the system to automatically set the filesystem to msdosfs on fat32 partitions.

Majorlag
02-10-2006, 04:41 PM
To be honest, I don't understand why this happens at all. The system should, as part of the process of halting, unmount all mounted filesystems. If it doesn't thats a bug with FreeBSD. Perhaps it will be fixed with 6.1? If not, I'll have to look into the FreeBSD shutdown process, it can probably be worked around by simply adding a script that says "umount -a".

Modifying the behavior of the drive detection system to not use "auto" would be a moderate pain, but it wouldn't be the best solution since the drive detection system has no way of knowing when a partition's filesystem has changed.