Karmic fails to report UUID

Bug #479590 reported by ofb
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu
Expired
Undecided
Unassigned

Bug Description

=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

Revision history for this message
Brian Murray (brian-murray) wrote :

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.

Changed in ubuntu:
status: New → Incomplete
Revision history for this message
ofb (cottlestonpie) wrote :
Download full text (9.4 KiB)

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()
...

Read more...

Revision history for this message
Chris Knight (cknight1234) wrote :

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

Revision history for this message
ofb (cottlestonpie) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.