/dev/disk/by-uuid doesn't exist in karmic kernels

Please supply the output of running "blkid"

Your udevdb records these symlinks:

/dev/sda:

S: disk/by-id/ata-STEC_ATA_DISK_vS020.1.0_STECD51608A10r88GBY3
S: disk/by-id/scsi-SATA_STEC_ATA_DISK_vSTECD51608A10r88GBY3
S: disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0

/dev/sda1:

S: disk/by-id/ata-STEC_ATA_DISK_vS020.1.0_STECD51608A10r88GBY3-part1
S: disk/by-id/scsi-SATA_STEC_ATA_DISK_vSTECD51608A10r88GBY3-part1
S: disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part1

Which is, as you say, missing by-uuid and by-label. There's notable no ID_FS_* keys, which suggests blkid is sulking

blkid gives no output at all.
I'm assuming from your comments that this bug is not in udev, but in blkid, so I'm changing the package to util-linux

Could you now run "blkid -p /dev/sda1" for me?

$ sudo blkid -p /dev/sda1
/dev/sda1: ambivalent result (probably more filesystems on the device)

I saw your comment on 433364 (which might be a duplicate of this bug since my partition is ext2) that explained what this output means. I did use jaunty's alternative installer for lpia to setup this drive though. Does my device actually have multiple metadata, or is it blkid returning a false positive? Also, how was vol_id able to work around this in Jaunty?

On Mon, 2009-10-12 at 19:20 +0000, Matt Drake wrote:

> $ sudo blkid -p /dev/sda1
> /dev/sda1: ambivalent result (probably more filesystems on the device)
>
> I saw your comment on 433364 (which might be a duplicate of this bug
> since my partition is ext2) that explained what this output means. I did
> use jaunty's alternative installer for lpia to setup this drive though.
> Does my device actually have multiple metadata, or is it blkid returning
> a false positive? Also, how was vol_id able to work around this in
> Jaunty?
>
It probably does - there are a couple of bugs where blkid is a little
more paranoid, and those are fixed upstream as part of a rewrite so we
can't merge them :-(

If you're feeling brave you could grab the util-linux-ng upstream source
and build the blkid from that, and see what that gives you?

Scott
--
Scott James Remnant
<email address hidden>

Thanks for your insight Scott.

With util-linux-ng 2.16.1 there's no change, but with git it works:

$ sudo ./blkid -p /dev/sda1
/dev/sda1: UUID="466063b6-fb62-4ebd-aadd-073d7ab92472" VERSION="1.0" TYPE="ext2" USAGE="filesystem"

While I understand that this won't make it into karmic, is there a chance that a git snapshot could either be uploaded to karmic-backports or a ppa?

On Thu, 2009-10-15 at 02:08 +0000, Matt Drake wrote:

> With util-linux-ng 2.16.1 there's no change, but with git it works:
>
> $ sudo ./blkid -p /dev/sda1
> /dev/sda1: UUID="466063b6-fb62-4ebd-aadd-073d7ab92472" VERSION="1.0" TYPE="ext2" USAGE="filesystem"
>
> While I understand that this won't make it into karmic, is there a
> chance that a git snapshot could either be uploaded to karmic-backports
> or a ppa?
>
Yes, I think we can do this - it'll be shortly after release though

Scott
--
Scott James Remnant
<email address hidden>

Matt: could you please also post the output of karmic blkid and the git blkid:

$ sudo su -
# BLKID_DEBUG=0xffff blkid -p /dev/sda1

Sure.

karmic:

# BLKID_DEBUG=0xffff blkid -p /dev/sda1
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 LABEL
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: magic sboff=56, kboff=1
ext2: call probefunc()
ext2_sb.compat = 00000000:00000002:00000001
assigning UUID
assigning VERSION
assigning TYPE
assigning USAGE
<-- leaving probing loop (type=ext2) [idx=23]
--> starting probing loop [idx=23]
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/sda1: ambivalent result (probably more filesystems on the device)

git:

# BLKID_DEBUG=0xffff ./blkid -p /dev/sda1
libblkid: debug mask set to 0xffff.
reseting blkid probe buffer
ready for low-probing, offset=0, size=0
chain safeprobe superblocks ENABLED
--> starting probing loop [SUBLKS 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()
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: magic sboff=56, kboff=1
ext2: call probefunc()
ext2_sb.compat = 00000000:00000002:00000001
assigning UUID [superblocks]
assigning VERSION [superblocks]
assigning TYPE [superblocks]
assigning USAGE [superblocks]
<-- leaving probing loop (type=ext2) [SUBLKS idx=23]
--> starting probing loop [SUBLKS idx=23]
jbd: magic sboff=56, kboff=1
jbd: call probefunc()
ufs: call probefunc()
sysv: call probefunc()
<-- leaving probing loop (failed) [SUBLKS idx=51]
chain safeprobe topology DISABLED
chain safeprobe partitions DISABLED
returning UUID value
/dev/sda1: UUID="466063b6-fb62-4ebd-aadd-073d7ab92472" returning VERSION value
VERSION="1.0" returning TYPE value
TYPE="ext2" returning USAGE value
USAGE="filesystem"

OK. It's clear from the git log that vfat detection has had some love recently:
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=history;f=shlibs/blkid/src/superblocks/vfat.c;h=2ba7ded10166b7413583441b7a19478ead5ed4c9;hb=HEAD

I just wanted to make sure this is not a duplicate of #428435.

This bug also prevented my machine from booting when I upgraded to Karmic. As a workaround, I added 'GRUB_DISABLE_LINUX_UUID=true' to my boot parameters, and changed 'root=UUID=foo' to 'root=/dev/sda1'. This allowed me to boot my machine.

PS -- Using the git version of blkid also worked for me. However, I couldn't see a non-hazardous way of using that version of blkid to boot (I would need to put it on the initramfs, right?), hence the above workaround.

I was hit by the same problem when upgrading to Karmic today (detected vfat and ext3). Git version also works here

# blkid -p /dev/sda1
/dev/sda1: ambivalent result (probably more filesystems on the device)
# ./blkid -p /dev/sda1
/dev/sda1: UUID="a7b855d8-8d49-494f-b24d-dfa26c4a5916" VERSION="1.0" TYPE="ext3" USAGE="filesystem"

I guess this is caused by the windows shipped with this computer and I'm pretty sure this will cause huge problems to "beginners" who will be left with an unusable system.

Isn't there some type of hotfix possible like cleaning the vfat signature from these partitions when upgrading to util-linux-ng?

Given that upstream has a fix for this, we should certainly apply this to karmic via SRU.

I have what looks to be the same problem, although for me the problem is not on my boot drive but a secondary drive. How should I work around it? Should I get the git version of blkid -- will this allow me to mount?

Currently I cannot even though I know the UUID that worked before with Jaunty Jackalope.

I also converted from Janunty to Karmic and had this problem. I have not tried the work around, but will shortly. One thing I want to add. I was trying to upgrade a Dell as was the person who originally posted the problem. Is there something unique to Dell BIOS or hardware that might be factor?

I've got a Fujitsu laptop and also experienced this problem, so I'd doubt this has something to do with Dell hardware.

I also converted from Jaunty to Karmic and had this problem too. I have tried the work-around: replacing the UUID with /dev/sdaN which is my /home partition. One thing I want to add is that I had to reboot a few times before the machine (Dell Latitude D810) would boot. It is curious that there is no /dev/sda1 symlink in the /dev/disk/by-uuid directory; nor is there a UUID value shown in gparted.

AT least I have a working machine ... phew!

I have this problem also. I added a second internal HDD to my desktop computer and thought that UUIDs would be a better method than the /dev/sdXY notation I'd been using, but I got the /dev/disk/by-uuid doesn't exist message.

Blkid does work for me in Karmic, but for some reason Karmic sees my original drive as /dev/sdb while Hardy sees the same drive as /dev/sda. Altering GRUB (legacy) to /dev/sdb for Karmic at least lets me boot. I also had to run update-initramfs before I could access other partitions properly from Karmic.

I have the same issue after upgrading to karmic with a mixed fs cd-rom containing rockridge, jolliet, hfs.
The cmd we use to create the image is (simplified):

$ mkisofs -A "SwissStick $(EDITION_USERFRIENDLY)" -J -r -V "SwissStick" \
        -cache-inodes \
        -exclude-list ../excludes \
        -hfs \
        -hfs-bless "/" \
        -iso-level 3 \
        -nobak \
        -sysid SwissStick-$(EDITION_USERFRIENDLY) \
               -D \
        -o ../swissstick-$(EDITION).iso .

If the CD-ROM filesystem contains HFS and Joliet and Rock Ridge (iso9660), it cannot decide whether it should be mounted as hfs or as iso9660. In Ubuntu older than Karmic Koala, it used to mount iso9660, which is exactly the behaviour we expect and wish: Different view on Mac (HFS), Linux (RockRidge) and Windows (Joliet). We include, exclude and hide programs so that every systems shows only the part relevant on that given system, i.e. on windows you see only "start.exe", on linux "start.sh", on mac "start.app".

The worst thing is, that now the CD-ROM icon does not even show for user-mount in the KDE/Gnome desktop. Either the user should be able to mount iso9660 (prefered), or there should be two mount-icons, one with label "Mount CD as Mac HFS Volume" and the other with label "Mount CD as Linux Volume".

> sudo BLKID_DEBUG=0xffff blkid -p /dev/sr1
libblkid: debug mask set to 0xffff.
reseting blkid_probe
ready for low-probing, offset=0, size=463319040
--> 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=510, kboff=0
vfat: call probefunc()
udf: magic sboff=1, kboff=32
udf: call probefunc()
iso9660: magic sboff=1, kboff=32
iso9660: call probefunc()
assigning LABEL
assigning VERSION
assigning TYPE
assigning USAGE
<-- leaving probing loop (type=iso9660) [idx=29]
--> starting probing loop [idx=29]
hfsplus: magic sboff=0, kboff=1
hfsplus: call probefunc()
hfs: magic sboff=0, kboff=1
hfs: call probefunc()
assigning LABEL
assigning TYPE
assigning USAGE
<-- leaving probing loop (type=hfs) [idx=32]
--> starting probing loop [idx=32]
ufs: call probefunc()
sysv: call probefunc()
<-- leaving probing loop (failed) [idx=49]
ERROR: ambivalent result detected (2 filesystems)!
/dev/sr1: ambivalent result (probably more filesystems on the device)

Will this ever be fixed in Karmic? Just upgraded from jaunty to karmic and lost 4 hours trying to figure out how to boot my system, an Acer travelmate 2480

Downloaded the git version of util-linux-ng, compiled (without fallocate because this fails due to absent fallocate64) and verified that the new blkid correctly recognizes my root partition:

$ cd util-linux-ng/misc-utils
$ ./blkid /dev/sda1
/dev/sda1: UUID="f9526843-5dda-4683-9588-41b864812487" TYPE="ext3"

OK, great. What am I supposed to do to correct this issue permanently? I see that doing "make install" will overwrite a lot of utilities, like mkfs, mkswap, etc. Is it safe to procceed and install the newly compiled util-linux-ng?

Thanks,

Lucid has a much newer util-linux

Hybrid CD-ROMs still cannot be handled in Lucid Lynx.

Now (in Lucid Lynx) the device appears in the desktop (KDE) devicemanager, but it still cannot be mounted. The only option that appears is: "copy with k3b"

When starting this option, k3b opens, but cannot recognize the CD-device.

In fact, devicemanager should recognize that there is a hybrid HFS/iso9660 (joliet/rockridge) CD-ROM, then offer the option: "Open CD_ROM in filemanager", which opens the iso9660/rockridge part (standard behaviour).

Or it could show options:
  - Open PC-Part (which is iso9660)
     - for Unix (which is rockridge)
    - for Windows (which is joliet)
  - Open Mac-Part (which is HFS)

BTW:

What happens behind the desktops devicemanager when a device is inserted?
Where could I add mount options (such as "-t iso9660")?
Where is the detection of the filesysem of a plugged-in USB-device?

I've been looking around for docs a long time, but it seems to have changed several time recently, so where is the magic now in latest ubuntu (karmic/lucid)?

Because that's most probably the location that must be patched ... and if I knew where, I probably could help.