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

Re: Bug#552578: udev: root partition's UUID not detected



On Wed, Oct 28, 2009 at 1:32 AM, Marco d'Itri <md@linux.it> wrote:
> On Oct 28, Martin-Éric Racine <q-funk@iki.fi> wrote:
>
>> $ sudo blkid -o udev -p /dev/hda1
>> /dev/hda1: ambivalent result (probably more filesystems on the device)
> Not my problem then. :-)

Searching the net for a solution, I located this somewhat related thread:

https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/428435

Based on this, I was able to determine that what probably happened is
that since this laptop started its life as a Windows machine and was
later converted to Debian, a Windows boot block apparently remained on
that partition's start:

$ sudo BLKID_DEBUG=0xffff blkid -p /dev/hda1
libblkid: debug mask set to 0xffff.
reseting blkid_probe
ready for low-probing, offset=0, size=0
--> starting probing loop [idx=-1]
linux_raid_member: call probefunc()
ddf_raid_member: call probefunc()
isw_raid_member: call probefunc()
lsi_mega_raid_member: call probefunc()
via_raid_member: call probefunc()
silicon_medley_raid_member: call probefunc()
nvidia_raid_member: call probefunc()
promise_fasttrack_raid_member: call probefunc()
highpoint_raid_member: call probefunc()
adaptec_raid_member: call probefunc()
jmicron_raid_member: call probefunc()
vfat: magic sboff=0, kboff=0
vfat: call probefunc()
assigning SEC_TYPE
assigning UUID
assigning VERSION
assigning TYPE
assigning USAGE
<-- leaving probing loop (type=vfat) [idx=16]
--> starting probing loop [idx=16]
ext4dev: magic sboff=56, kboff=1
ext4dev: call probefunc()
ext4: magic sboff=56, kboff=1
ext4: call probefunc()
ext3: magic sboff=56, kboff=1
ext3: call probefunc()
ext2_sb.compat = 00000024:00000006:00000003
assigning LABEL
assigning UUID
assigning VERSION
assigning TYPE
assigning USAGE
<-- leaving probing loop (type=ext3) [idx=22]
--> starting probing loop [idx=22]
ext2: magic sboff=56, kboff=1
ext2: call probefunc()
jbd: magic sboff=56, kboff=1
jbd: call probefunc()
ufs: call probefunc()
sysv: call probefunc()
<-- leaving probing loop (failed) [idx=49]
ERROR: ambivalent result detected (2 filesystems)!
/dev/hda1: ambivalent result (probably more filesystems on the device)
$

My best guess is that since GRUB itself was installed on the MBR, the
boot block on /dev/hda1 simply wasn't deleted by mke2fs back then and
this has suddenly become an issue, with everyone having switched from
Ted Tso's e2fstools to the generic linux-utils-ng version of blkid.

My question is now, how can I delete this remnant of a VFAT partition
without having to reinstall the whole system?   Is there any tool that
could be used to zero the boot blocks of all partitions, but leave the
MBR untouched?

The above Launchpad thread offers a small script that can clear
ext2/ext3/ext4/swap filesystem signatures and that could be used as a
starting point for a more versatile filesystem linting tool.  I don't
know anything about Python or the tools it calls, but I'm sure that
someone on the util-linux maintainer team would be able to figure this
one fairly quickly.

A secondary question is, what guarantees that debian-installer
wouldn't skip such ambiguous filesystem signatures on a fresh install
also?

-- 
Martin-Éric


Reply to: