On Wed, Oct 28, 2009 at 1:32 AM, Marco d'Itri <m...@linux.it> wrote: > On Oct 28, Martin-Éric Racine <q-f...@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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org