Karmic fails to report UUID

[ofb]

=Karmic LiveCD=

ubuntu@ubuntu:~$ ls /dev/disk/by-uuid/
500ae9f4-7cbb-4657-807d-fbc48385eb5b a53ac1fd-b24e-4de4-9328-eba25c6cf59b
626a140e-b774-4695-978b-8f01d8ea984e f7e6f14b-a76e-4329-9d60-d50c0580a1f1

=Jaunty LiveCD=

ubuntu@ubuntu:~$ ls /dev/disk/by-uuid/
2500e823-24dc-4a8c-8a55-2054e4d6c144 a53ac1fd-b24e-4de4-9328-eba25c6cf59b
500ae9f4-7cbb-4657-807d-fbc48385eb5b f7e6f14b-a76e-4329-9d60-d50c0580a1f1
626a140e-b774-4695-978b-8f01d8ea984e

I hit this during upgrade. The missing UUID is my /home partition, so it was not a fun upgrade. (Thread: http://ubuntuforums.org/showthread.php?p=8276846 )

I used a kludge to proceed. The stray UUID in my fstab has been replaced by the path /dev/sda1.

=Karmic LiveCD=

Palimpsest shows the partition as "Unrecognized".
GParted shows the partition as normal, although without a mount point listed.
Nautilus shows /home as empty.
'lshw' shows sda1 and the correct UUID.

=Karmic install=

Palimpsest shows the partition as "Unrecognized".
GParted shows the partition as normal, with correct mount point.
Nautilus shows /home correctly.
'lshw' shows sda1 and the correct UUID.

Install boots after showing this error:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
/home: waiting for /dev/sda1
/home/o/Thorax_B: waiting for /dev/disk/by-uuid/f7e6f[etc]
/home/o/Thorax_A: waiting for /dev/disk/by-uuid/500ae[etc]
Press ESC to enter a recovery shell

Originally it showed this error and did not boot:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
/home: waiting for UUID=2500e823[etc]
/home/o/Thorax_B: waiting for /dev/disk/by-uuid/f7e6f[etc]
/home/o/Thorax_A: waiting for /dev/disk/by-uuid/500ae[etc]
Press ESC to enter a recovery shell

[Brian Murray (brian-murray)]

This bug might be a duplicate of bug 428435. Can you check the output of:

sudo blkid /dev/sda1

or you might get more detailed output from the following:

    $ sudo su -
    # BLKID_DEBUG=0xffff blkid

Thanks in advance.

[ofb (cottlestonpie)]

Thanks for having a look. Here's the two outputs.

o@redfish:~$ sudo blkid /dev/sda1
[sudo] password for o:
o@redfish:~$

o@redfish:~$ sudo su -
root@redfish:~# BLKID_DEBUG=0xffff blkid
libblkid: debug mask set to 0xffff.
creating blkid cache (using default cache)
reading config file: /etc/blkid.conf.
Begin blkid_probe_all()
read partition name sda
read partition name sda1
partition dev sda1, devno 0x0801
need to revalidate /dev/sda1 (cache time 2147483648, stat time 1257791022,
 time since last check 3405313875)
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 UUID
assigning TYPE
<-- 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 = 00000004:00000006:00000001
assigning UUID
assigning TYPE
<-- 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)!
  freeing dev /dev/sda1 ((null))
  dev: name = /dev/sda1
  dev: DEVNO="0x0"
  dev: TIME="-2147483648"
  dev: PRI="0"
  dev: flags = 0x00000000

reseting blkid_probe
read partition name sda2
partition dev sda2, devno 0x0802
read partition name sda3
partition dev sda3, devno 0x0803
need to revalidate /dev/sda3 (cache time 2147483648, stat time 1257791006,
 time since last check 3405313875)
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()
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 = 0000003C:00000006:00000003
assigning UUID
assigning TYPE
<-- 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()
...

[Chris Knight (cknight1234)]

I have a similar problem. This may be a duplicate of 464411 and 428318, the latter of which proposes several solutions.

[ofb (cottlestonpie)]

Okay, my machine is no longer available for test output. I've fixed it per this post.
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/464411/comments/22

This seems to be the most informative bug report.
https://bugs.launchpad.net/ubuntu/+bug/428318

I can confirm my drive was once formatted as fat before going ext3, and very likely only that partition.

I would suggest that my report here be marked as a duplicate by an experienced member if they agree.

----

Quick uneducated summary - Lawrence Rust found the new blkid trips on partitions with multiple metadata, whereas the previous one didn't. I can't say why GParted would leave behind fat metadata when converting to ext2/3. Possibly it should be what gets fixed.

Which I'll hazard means we may not see a patch that avoids this problem for people who already have residual fat metadata on their partitions. Which does beg the question of what should be done for them.

Lacking a better idea, should a warning at least be added to the Karmic Release Notes? (Does Launchpad handle that, or should another team be notified?)
http://www.ubuntu.com/getubuntu/releasenotes/910

[Launchpad Janitor (janitor)]

[Expired for Ubuntu because there has been no activity for 60 days.]