[arch-general] Error message on mkinitcpio

[Thomas Bächler]

Am 14.02.2010 17:38, schrieb Ray Kohler:
> On Fri, Feb 12, 2010 at 3:02 AM, Thomas Bächler <thomas at archlinux.org> wrote:
>> Am 12.02.2010 03:26, schrieb Tomás Acauan Schertel:
>>> I still got error message after using packages from [testing].
>>> Am I doing something wrong??
>>
>> Is the line number still 17?
> 
> I was surprised to still see this autodetect error after upgrading to
> the glibc-based mkinitcpio, so apparently Pierre's fix wasn't the
> whole fix.
> 
> I have an understanding of why I saw it now: blkid detected my swap as
> a VFAT filesystem (which used to be there before), and so it had a
> very short UUID (something like 3030-3030). Apparently the autodetect
> hook doesn't like that. I dd'ed zeros over the swap and re-created it,
> so that it now has a "normal" UUID and the right type given by blkid,
> changed UUID in fstab, and the autodetect error went away.
> 
> I don't know if this is something we really care about. Probably it's
> worth making it work for UUIDs of strange lengths, but no so
> interesting to cover over problems from people (like me, apparently)
> who just have wrong data written on their disks.

It is a very old story that has been discussed at length on the
util-linux-ng mailing list:

Some file system creation tools (in particular cryptsetup and mkswap)
didn't overwrite file system signatures left behind by other file
systems. This lead to data corruption, destroyed file systems and the
like. Thus, blkid refuses to detect file systems if it finds signatures
for more than one file system.

The command "blkid -o udev -p /dev/XXX" will print:
 ID_FS_AMBIVALEN=filesystem:vfat:1 other:swap:2
and eval'ing that line will (due to the lack of quotes) result in your
error message (I just found this out a few minutes ago, and thus can now
explain your error message).

This is particularly bad if your root file system is affected: The old
vol_id from udev just used the first signature it found and we could
thus mount it, but we use blkid in initramfs now: Your file system type
won't be detected on boot and mounting will fail, thus booting will
fail. Just a few minutes ago, I investigated a case where there was an
ambiguity between minix and ext3.

We also had discussions about this when udev first switched from vol_id
to blkid, because /dev/disk/by-{uuid,label} entries were missing for the
same reason.

Suffice it to say, current versions of cryptsetup and mkswap do
overwrite other file system signatures properly. But old volumes might
still suffer from these problems.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20100214/a77d5367/attachment-0001.bin>