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

[Matt Drake]

Binary package hint: udev

I have a Dell Mini that I upgraded from Jaunty to Karmic, and when booting the Karmic kernel, /dev/disk/by-uuid doesn't exist, which causes some problems in booting since uuids are used by default. When I still had the Jaunty kernel hanging around, it would have /dev/disks/by-uuid

So here's what I got in /dev/dsik:
$ ls -l /dev/disk/
total 0
drwxr-xr-x 2 root root 120 2009-09-07 17:19 by-id
drwxr-xr-x 2 root root 80 2009-09-07 17:19 by-path

ProblemType: Bug
Architecture: lpia
Date: Mon Sep 7 17:48:00 2009
DistroRelease: Ubuntu 9.10
MachineType: Dell Inc. Inspiron 910
NonfreeKernelModules: wl
Package: udev 146-1
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: root=/dev/sda1 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-9.29-lpia
SourcePackage: udev
Tags: ubuntu-unr
Uname: Linux 2.6.31-9-lpia i686
dmi.bios.date: 03/05/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A05
dmi.board.name: CN0J14
dmi.board.vendor: Dell Inc.
dmi.board.version: A05
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A05
dmi.modalias: dmi:bvnDellInc.:bvrA05:bd03/05/2009:svnDellInc.:pnInspiron910:pvrA05:rvnDellInc.:rnCN0J14:rvrA05:cvnDellInc.:ct8:cvrA05:
dmi.product.name: Inspiron 910
dmi.product.version: A05
dmi.sys.vendor: Dell Inc.

[Scott James Remnant (Canonical) (canonical-scott)]

Please supply the output of running "blkid"

[Scott James Remnant (Canonical) (canonical-scott)]

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

[Matt Drake (mattduckman)]

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

[Scott James Remnant (Canonical) (canonical-scott)]

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

[Matt Drake (mattduckman)]

$ 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?

[Scott James Remnant (Canonical) (canonical-scott)]

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>

[Matt Drake (mattduckman)]

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?

[Scott James Remnant (Canonical) (canonical-scott)]

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>

[Antti Kaijanmäki (kaijanmaki)]

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

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

[Matt Drake (mattduckman)]

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"

[Antti Kaijanmäki (kaijanmaki)]

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.

[Ben Willmore (bdeb)]

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.

[Ben Willmore (bdeb)]

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.

[genesis (s-launchpad-mail-syndos-de)]

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?

[Steve Langasek (vorlon)]

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

[Andrew Burns (home-a-burns)]

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.

[knowsgrace (knowsgrace)]

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?

[Moritz Baumann (mo42)]

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

[ubundominic (dominic-edmonds)]

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!

[Jane Atkinson (irihapeti)]

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.

[Nick Hangartner (nhangartner)]

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 .

[mrw (marc-waeckerlin)]

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)

[Austriaco (lanieves)]

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

[Austriaco (lanieves)]

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,

[Scott James Remnant (Canonical) (canonical-scott)]

Lucid has a much newer util-linux

[mrw (marc-waeckerlin)]

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)

[mrw (marc-waeckerlin)]

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.