[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#548290: A solution (for me, at least)



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



Reply to: