On Thu, 2006-08-17 at 22:46 -0700, Andrew Pimlott wrote: > I suspect I have a similar problem to the reporter of this bug. I have > a swap partition that is set up as an encrypted dm device with a random > key, using the cryptsetup package. cryptsetup now has a test that calls > vol_id, which thinks that my partition is vfat: > > % sudo /lib/udev/vol_id /dev/hda2 > ID_FS_USAGE=filesystem > ID_FS_TYPE=vfat > ID_FS_VERSION=FAT32 > ID_FS_UUID= > ID_FS_LABEL= > ID_FS_LABEL_SAFE= > > % sudo mount -t vfat /dev/hda2 /mnt/tmp > mount: /dev/hda2: can't read superblock > > Inspecting this partition, I see clearly "MSDOS5.0", presumably the > long-preserved remnants of a vfat filesystem. However, since the kernel > refuses to mount the partition as vfat, it seems that vol_id could apply > a stricter check. > > I realize that vol_id can never be perfect, since the device metadata > may be consistent with multiple formats. And I agree that device > initialization tools (like mkswap) should zero out part of the device. > But it would still help to make vol_id more exact, because this issue > evidently bites users in practice. Perhaps there could be flags for > quick-and-dirty check versus more complete check.
It's almost impossible to make libvolume_id stricter, in most cases, even the kernel mounts a mkswap formatted (and obviously corrupt) fat volume just fine and allows writing to it. It's mkswap which is horribly broken here and needs to be fixed. You can just use dd and clean the volume before reformatting it. I talked to the former maintainer of mkswap long ago and he said it's a 'feature' of mkswap not to overwrite anything not needed for the swap signature - so far, he seem not to have the slightest clue what all this is about. The maintainer has changed in the meantime, which is great, so we may have a chance to fix that now, but I didn't try to talk to him. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
