Hi, A little bit more digging, and I think I know what's going on, for me at least. (Other reporters' experience might vary)
The machine in question originally had Windows installed on it; the Linux installation was performed several years ago now, and completely wiped all traces of Windows from the machine (i.e. reused the entire disk, not resizing partitions and using empty space). This reassignment of the partition, however, didn't (and probably still doesn't) write zeros everywhere; as I understand it, there are some bits of the superblock left untouched by a repartitioning like this. Meanwhile, the blkid command (or rather the partition detection logic in libblkid1) in util-linux-ng was rewritten recently. The new logic, present in util-linux_2.16-4 (i.e. the version in testing and unstable as I write) is not sufficiently robust in its detection, and returns a false positive of vfat, based on the remnants of the disk superblock from way back when, as well as the ext3 filesystem that is really there. The blkid command, again as I understand it, is called to populate the /dev/disk/by-uuid/ directory in the initramfs. If it "detects" two filesystems simultaneously, the uuid is not inserted (it's treated as a failure). This explains both why the disk does not show up in the initramfs /dev/disk/by-uuid directory, and also why it's only affecting this newer (2.6.30-2) kernel on my system: that's the only one whose initramfs has been generated using the new blkid. The solution that I have found acceptable is to apply the last patch in <https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/428318>: specifically, the patch to make vfat detection more robust at <http://launchpadlibrarian.net/33034738/util-linux-ng-2.16.1.patch>. (This patch has already made it into util-linux-ng's upstream repository, but so has a lot else :-) Then regenerating the affected initramfs with update-initramfs -k 2.6.30-2-686 -u gave me a booting system. So to summarize, this isn't (at least for me) a bug in the kernel image, but with the util-linux-ng tools, and maybe this solution (or others documented in the launchpad bug threads, such as writing zeros to the first 512 bytes of the partition -- I didn't feel brave enough to do that) will help the other people reporting this bug here. Best, Christophe -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
