Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Fri, 18 Aug 2006, Kay Sievers wrote: On Fri, 2006-08-18 at 08:59 -0700, Andrew Pimlott wrote: On Fri, Aug 18, 2006 at 02:13:53PM +0200, Kay Sievers wrote: 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. Ok, thanks for the explanation. It's mkswap which is horribly broken here and needs to be fixed. Hopefully the bug I filed with util-linux will produce some change. That would be nice. In case you need to argue, the mkfs.ext* tools and mkfs.reisferfs tools invalidate the start and the end (md raid) of the volume too, to overwrite old signatures after having the same problems. You can just use dd and clean the volume before reformatting it. Right--I've done that to the partition, and now I have no problem. Yeah, but it's bad, that we need to do this after that issue is known for more than a year now. Thanks, Kay on the same line it would be cool if mkswap checked what it is doing. as currently it doesn't do much: you can easily recover any mkswaped partition. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
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. I can send the strace output from running vol_id on this partition if somebody would like to look at it. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
To follow up, I just filed bug 383581 against util-linux (the package of mkswap). I chose to pick on mkswap because that was the case I could reproduce--indeed, it leaves the first 1k (containing MSDOS5.0) untouched; whereas mke2fs overwrote it. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
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]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Fri, 2006-08-18 at 08:59 -0700, Andrew Pimlott wrote: On Fri, Aug 18, 2006 at 02:13:53PM +0200, Kay Sievers wrote: 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. Ok, thanks for the explanation. It's mkswap which is horribly broken here and needs to be fixed. Hopefully the bug I filed with util-linux will produce some change. That would be nice. In case you need to argue, the mkfs.ext* tools and mkfs.reisferfs tools invalidate the start and the end (md raid) of the volume too, to overwrite old signatures after having the same problems. You can just use dd and clean the volume before reformatting it. Right--I've done that to the partition, and now I have no problem. Yeah, but it's bad, that we need to do this after that issue is known for more than a year now. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Fri, Aug 18, 2006 at 02:13:53PM +0200, Kay Sievers wrote: 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. Ok, thanks for the explanation. It's mkswap which is horribly broken here and needs to be fixed. Hopefully the bug I filed with util-linux will produce some change. You can just use dd and clean the volume before reformatting it. Right--I've done that to the partition, and now I have no problem. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
