FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 11-08-2009, 04:23 PM
Christophe Rhodes
 
Default 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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-10-2009, 12:04 PM
Jaap Keuter
 
Default Bug#548290: A solution (for me, at least)

Hi Christophe,

Good work. I found this bug on util-linux pertaining to this issue: udev:
root partition's UUID not detected
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552578





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 02:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org