On Tue, Nov 11, 2008 at 15:29, Matt Behrens <matt@xxxxxxxx> wrote: > The Palm LifeDrive and T|X have a "Drive Mode" functionality that exposes > the onboard FAT32 partitions as USB drives. However, Palm's idea of what > constitutes a FAT32 partition is a bit... weak. ;) Below are Matthew > Garrett's insights on the filesystem probe failure from the hal list; > he suggested I get in touch with the udev developers. > > I've made an image of a newly-formatted partition and posted it at > http://launchpadlibrarian.net/19129151/sdb1.img.bz2 and the Ubuntu bug > with more info can be found at > https://bugs.launchpad.net/ubuntu/+source/hal/+bug/81219. > > It's unfortunately not enough to format the partition with mkdosfs or > fsck it into compliance; the device will "fix" the partition at some > point in the future rendering it unmountable again. Nice! Seems really smart. :) > (Thought you can > force-mount it with a -t vfat.) > > ----- Forwarded message from Matthew Garrett <mjg59@xxxxxxxxxxxxx> ----- > > From: Matthew Garrett <mjg59@xxxxxxxxxxxxx> > To: Matt Behrens <matt@xxxxxxxx> > Subject: Re: LifeDrive and T|X not seen by hal > > Ok. The following things appear to be causing the failure: > > 1) The FAT signature in bytes 510 and 511 isn't present. This causes the > code to bail. > > 2) The FAT32 signature in the fsinfo block isn't present. This causes > the code to bail. Hmm, we can not really remove these checks, as there are many volumes out there which we would detect as FAT, which are not FAT. Most of these additional checks only got added after a several reports of mis-detection. Even partition tables may get detected as FAT, if we remove these checks, without adding new ones. > 3) The loop looking for the root dir appears to jump out past the code > that sets the filesystem label. This results in it ignoring the UUID > and filesystem name. Is it recognized as FAT, but we jump out of it? Or do we decide that it is not FAT at all? Is it something that we can fix? > You probably need to get in touch with the udev developers to get this > fixed - I'm not sure which of these checks could result in false > positives unless care is taken. Once libvolume_id is fixed hal should > just work. I guess, someone should try to get Palm to come up with a fix for that thing they call FAT. :) Maybe we should always probe for all known filesystems, and not stop at the first match. And if we only find FAT, and nothing else, we might be able to say it's FAT even with less strict checks. Adding Karel to Cc, because we plan to merge volume_id and blkid some day. It's a really scary thing, to guess filesystems based on a few bytes we read out of a random byte stream. Other operating systems have far less trouble to have less checks, because they don't support several dozens of filesystems, and usually have formatting applications which are not that broken as the Linux ones, regarding to clearing out old signatures before applying a new format. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
