After upgrade to Karmic, root partition (sda1) is missing /dev/sda1 is missing from /dev/disk/by-uuid

[Andreas Schildbach]

After upgrading of a working Jaunty to Karmic final, it would not boot into the system and instead hang in the initramdisk. I did NOT yet upgrade to ext4 or grub2.

Booting with recovery mode reveals that it could not find my main partition sda1 (which contains my now Karmic installation).

Booting into a second karmic system on sda2 reveals that sda1 is indeed not visible any more:

$ ls -la /dev/disk/by-uuid
total 0
drwxr-xr-x 2 root root 80 Oct 30 09:22 .
drwxr-xr-x 6 root root 120 Oct 30 09:22 ..
lrwxrwxrwx 1 root root 10 Oct 30 09:22 500a11a1-86bd-4609-96ca-78797dfb772b -> ../../sda5
lrwxrwxrwx 1 root root 10 Oct 30 09:22 b17e1aff-9f02-4fbd-81e5-9b1e6899baad -> ../../sda2

Nevertheless, I can mount my main partition when I directly mount /dev/sda1 from the second installation, so the filesystem is intact.

When I start "Palimpsest", it shows my first partition as "54 GB unrecognized", which is a bit startling.

[Georgi (gkourtev)]

I have simmilar issue while upgrading. After reboot, it says that cannot mount listed in /etc/fstab. dpkg does not work as the system says it is read only.

[Andreas Schildbach (schildbach)]

@Georgi: can you post the relevant line from your fstab?

[Johan Kiviniemi (ion)]

Andreas,

Please attach /var/log/udev and paste the output of sudo blkid.

[Andreas Schildbach (schildbach)]

My partition table is listed as follows:

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x23f12d67

   Device Boot Start End Blocks Id System
/dev/sda1 1 6551 52620876 83 Linux
/dev/sda2 * 6552 7139 4723110 83 Linux
/dev/sda3 7140 7296 1261102+ 5 Extended
/dev/sda5 7141 7296 1253070 82 Linux swap / Solaris

[Andreas Schildbach (schildbach)]

$ sudo blkid
/dev/sda2: LABEL="experimental" UUID="b17e1aff-9f02-4fbd-81e5-9b1e6899baad" TYPE="ext3"
/dev/sda5: UUID="500a11a1-86bd-4609-96ca-78797dfb772b" TYPE="swap"

note that /dev/sda1 is missing!

[Andy Whitcroft (apw)]

Note that udev has seen the device, and indeed as you can use manual mount of /dev/sda1 has made the devices:

  UDEV [1256891017.380067] add /devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/sda1 (block)

So that looks like blkid is the issue here.

[Daniel Holbach (dholbach)]

Stefan Bader indicated this could well be a util-linux bug.

[Andy Whitcroft (apw)]

Can we confirm whether the /dev/sda1 was present after boot and fail into initramfs.

[Andreas Schildbach (schildbach)]

After it fails and drops into BusyBox / initramfs, I can see - by using ls -

sda5
sda2
sda1

devices in /dev.

sda1 is also linked in /dev/disk/by-id and /dev/disk/by-path

It is NOT linked in /dev/disk/by-uuid and /dev/disk/by-label (afair it has no label, so this might by expected)

Andy, does this answer your question?

[Andreas Schildbach (schildbach)]

Is this related to bug 428318?

[Andreas Schildbach (schildbach)]

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

Aaaarrgh!

[Andreas Schildbach (schildbach)]

Seems like blkid is detecting an ext3 AND a vfat on that partition:

$ sudo 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_sb.compat = 00000004: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/sda1: ambivalent result (probably more filesystems on the device)

[steakunderscore (steakunderscore)]

What hardware is this issue on. I am having trouble with a a8n sli delux mother board as it has a 'fake raid' controller.

[Georgi (gkourtev)]

It says:

$ls -la /dev/disk/by-uuid
total 0
drwxr-xr-x 2 root root 80 2009-10-30
drwxr-xr-x 6 root root 120 2009-10-30
lrwxrwxrwx 1 root root 10 2009-10-30 01cceacc-c363-4295-8e9a-3792c9aa855d
->../../sda1
rwxrwxrwx 1 root root 10 2009-10-30 4ef950ca-a29d-49df-a317-5d4ab18951a2
->../../sda5

2009/10/30 Andreas Schildbach <email address hidden>

> @Georgi: can you post the relevant line from your fstab?
>
> ** Package changed: ubuntu => linux (Ubuntu)
>
> --
> After upgrade to Karmic, root partition (sda1) is missing /dev/sda1 is
> missing from /dev/disk/by-uuid
> https://bugs.launchpad.net/bugs/464411
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “linux” package in Ubuntu: New
>
> Bug description:
> After upgrading of a working Jaunty to Karmic final, it would not boot into
> the system and instead hang in the initramdisk. I did NOT yet upgrade to
> ext4 or grub2.
>
> Booting with safe mode reveals that it could not find my main partition
> (which contains my now Karmic installation).
>
> Booting into a second karmic system on the sda2 reveals that sda1 is indeed
> not visible any more:
>
> $ ls -la /dev/disk/by-uuid
> total 0
> drwxr-xr-x 2 root root 80 Oct 30 09:22 .
> drwxr-xr-x 6 root root 120 Oct 30 09:22 ..
> lrwxrwxrwx 1 root root 10 Oct 30 09:22
> 500a11a1-86bd-4609-96ca-78797dfb772b -> ../../sda5
> lrwxrwxrwx 1 root root 10 Oct 30 09:22
> b17e1aff-9f02-4fbd-81e5-9b1e6899baad -> ../../sda2
>
> Nevertheless, I can mount my main partition when I directly mount /dev/sda1
> from the second installation, so the filesystem is intact.
>
> When I start "Palimpsest", it shows my first partition as "54 GB
> unrecognized", which is a bit startling.
>
>
>

[Andy Whitcroft (apw)]

@Andreas -- yes that output pretty much confirms this is the blkid bug you indicated. I will dup this bug against that one.

[Andreas Schildbach (schildbach)]

I solved this for me by running

sudo dd bs=512 count=1 if=/dev/zero of=/dev/sda1

which removes the vfat identifier from the partition but leaves ext3 intact. Remember to replace sda1 with your problematic partition.

[Hubert FONGARNAND (hfongarnand)]

I have exactly the same problem /dev/sda1 is my boot partition....

[Hubert FONGARNAND (hfongarnand)]

hfongarnand@hub-ubuntu:~$ sudo 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 LABEL
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)

[Hubert FONGARNAND (hfongarnand)]

solved too by running

sudo dd bs=512 count=1 if=/dev/zero of=/dev/sda1

[mindseye1 (mindseye11)]

I'm smart enough to know that I shouldn't just use DD for any old solution, but I'm not smart enough to know what this actual DD statement will do to my system. I am having this same issue, sda1 no longer appears to have a UUID. But before I run the shown DD statement I was wondering if anyone could explain what it will do and what the consequences might be. Will this only be erasing my MBR? Will I have to reinstall GRUB afterwards? I really want to solve this, but I don't want to risk typing in a DD statement without knowing what it will do. Thanks!

[Andreas Schildbach (schildbach)]

@mindseye1: First, you should run "sudo blkid -p /dev/sda1" and make sure it returns "/dev/sda1: ambivalent result (probably more filesystems on the device)" (substitute sda1 by your missing partition)

This means that there is a vfat header in the first block (512 bytes) of the partition and an ext2/3 header in the following blocks.

Next, you should make a full and verified backup of your partition, in case anything goes wrong (e.g. by mounting with an old live-CD).

Last, "sudo dd bs=512 count=1 if=/dev/zero of=/dev/sda1" zeros the first block, thus removing the vfat header. Note the MBR will be unaffected by this.

It is generally a good idea to read the manpages of the commands you are told to execute (e.g. "man dd").