Good morning!
Before filing a bug, I want to see what you have to say :)
I did an FC12 installation on my Ultra 5 and noticed something weird.
[root@medusa /]# blkid /dev/sda1: UUID="5227bdcc-de97-4a1a-8d01-49e06e882771" TYPE="ext3" /dev/sda3: UUID="5227bdcc-de97-4a1a-8d01-49e06e882771" TYPE="ext3" /dev/sdb1: UUID="90a9428f-72c6-ae35-e4e6-37e93e5dd7b5" TYPE="linux_raid_member" /dev/sdc1: UUID="7fd60fe3-8252-40e8-8ec4-8790287eb8e8" TYPE="ext4" /dev/sdc2: UUID="e07227d5-8519-44b7-a046-75406f2598ce" TYPE="swap" /dev/sdc3: UUID="7fd60fe3-8252-40e8-8ec4-8790287eb8e8" TYPE="ext4" /dev/sdc4: UUID="01d42e64-932b-4abb-98f0-5c78807e8b06" TYPE="ext4" /dev/sdc5: UUID="8e47e08c-4918-452d-a266-d26d8185c106" TYPE="ext4"
Note how all first slices and the third slices on both my ATA and SATA disk are duplicates. This becomes very problamatic during booting.
silo.conf by default after installation uses root=UUID="7fd60fe3-8252-40e8-8ec4-8790287eb8e8". The kernel panics, mentions "you have to specify a filesystem" and sleeps forever.
My assumption is, that due to the duplicated UUIDs, it tries to mount /dev/sdc, since /dev/sdc3 is the Sun/Solaris equilivent to "Whole disk" and fdisk highly recommends you to have this /dev/sd?3 as "Whole disk" partition. (As Solaris has slice 2 as whole disk).
/etc/fstab has problems too. It tries to mount both / and /export with the same UUID, again
UUID=7fd60fe3-8252-40e8-8ec4-8790287eb8e8 / ext4 defaults 1 1 UUID=7fd60fe3-8252-40e8-8ec4-8790287eb8e8 /export ext4 defaults 1 2
Another problem in /etc/fstab is that it tries to mount filesystems based on UUIDs that don't exist. [root@medusa /]# grep /slowdrive /etc/fstab #UUID=8bd7d37d-21fb-4da5-9865-c20cc07ca6be /slowdrive ext3 defaults 1 2
[root@medusa /]# blkid | grep 8bd7d37d-21fb-4da5-9865-c20cc07ca6be [root@medusa /]#
Any ideas what is going on?
Patrick
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any ideas what is going on?
Pretty much exactly what you describe is going on. Something in blkid's handling doesn't deal properly with Sun Whole Disk types.
It is a known bug, haven't had time lately to put a lot of time into it.
~spot
On 3/4/2010 2:56 PM, Tom "spot" Callaway wrote:
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any ideas what is going on?
Pretty much exactly what you describe is going on. Something in blkid's handling doesn't deal properly with Sun Whole Disk types.
It is a known bug, haven't had time lately to put a lot of time into it.
This is an easy fix.
David M. and I worked together to make sure that /sysfs did export a whole_disk attribute for a full disk slices.
An ad-hoc udev rule change to skip creation/handling of those devices will work just fine and it´s useful on all architecture (also for BSD formatted block devices).
System-wide there is no practical use of those anyway, and they are still visible to partitioning tools.
Cheers Fabio
On 03/05/2010 03:08 AM, Fabio M. Di Nitto wrote:
On 3/4/2010 2:56 PM, Tom "spot" Callaway wrote:
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any ideas what is going on?
Pretty much exactly what you describe is going on. Something in blkid's handling doesn't deal properly with Sun Whole Disk types.
It is a known bug, haven't had time lately to put a lot of time into it.
This is an easy fix.
David M. and I worked together to make sure that /sysfs did export a whole_disk attribute for a full disk slices.
An ad-hoc udev rule change to skip creation/handling of those devices will work just fine and it´s useful on all architecture (also for BSD formatted block devices).
Could you write a patch against udev for this? Udev is kindof a black magic thing for me. :)
~spot
On 3/5/2010 3:16 PM, Tom "spot" Callaway wrote:
On 03/05/2010 03:08 AM, Fabio M. Di Nitto wrote:
On 3/4/2010 2:56 PM, Tom "spot" Callaway wrote:
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any ideas what is going on?
Pretty much exactly what you describe is going on. Something in blkid's handling doesn't deal properly with Sun Whole Disk types.
It is a known bug, haven't had time lately to put a lot of time into it.
This is an easy fix.
David M. and I worked together to make sure that /sysfs did export a whole_disk attribute for a full disk slices.
An ad-hoc udev rule change to skip creation/handling of those devices will work just fine and it´s useful on all architecture (also for BSD formatted block devices).
Could you write a patch against udev for this? Udev is kindof a black magic thing for me. :)
I am PTO as of 2 hours ago :) but I´ll see you Tue and/or Wed in Westford. I am fairly sure the udev rule is still shipped in Ubuntu, we just need to find it and copy it.
Fabio
On 03/05/2010 10:22 AM, Fabio M. Di Nitto wrote:
On 3/5/2010 3:16 PM, Tom "spot" Callaway wrote:
On 03/05/2010 03:08 AM, Fabio M. Di Nitto wrote:
On 3/4/2010 2:56 PM, Tom "spot" Callaway wrote:
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any ideas what is going on?
Pretty much exactly what you describe is going on. Something in blkid's handling doesn't deal properly with Sun Whole Disk types.
It is a known bug, haven't had time lately to put a lot of time into it.
This is an easy fix.
David M. and I worked together to make sure that /sysfs did export a whole_disk attribute for a full disk slices.
An ad-hoc udev rule change to skip creation/handling of those devices will work just fine and it´s useful on all architecture (also for BSD formatted block devices).
Could you write a patch against udev for this? Udev is kindof a black magic thing for me. :)
I am PTO as of 2 hours ago :) but I´ll see you Tue and/or Wed in Westford. I am fairly sure the udev rule is still shipped in Ubuntu, we just need to find it and copy it.
Hmm, assuming it is this line in 60-persistent-storage.rules:
# ignore partitions that span the entire disk TEST=="whole_disk", GOTO="persistent_storage_end"
... we already have that.
~spot
On 3/5/2010 4:30 PM, Tom "spot" Callaway wrote:
On 03/05/2010 10:22 AM, Fabio M. Di Nitto wrote:
On 3/5/2010 3:16 PM, Tom "spot" Callaway wrote:
On 03/05/2010 03:08 AM, Fabio M. Di Nitto wrote:
On 3/4/2010 2:56 PM, Tom "spot" Callaway wrote:
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any ideas what is going on?
Pretty much exactly what you describe is going on. Something in blkid's handling doesn't deal properly with Sun Whole Disk types.
It is a known bug, haven't had time lately to put a lot of time into it.
This is an easy fix.
David M. and I worked together to make sure that /sysfs did export a whole_disk attribute for a full disk slices.
An ad-hoc udev rule change to skip creation/handling of those devices will work just fine and it´s useful on all architecture (also for BSD formatted block devices).
Could you write a patch against udev for this? Udev is kindof a black magic thing for me. :)
I am PTO as of 2 hours ago :) but I´ll see you Tue and/or Wed in Westford. I am fairly sure the udev rule is still shipped in Ubuntu, we just need to find it and copy it.
Hmm, assuming it is this line in 60-persistent-storage.rules:
# ignore partitions that span the entire disk TEST=="whole_disk", GOTO="persistent_storage_end"
... we already have that.
I can´t check it myself right away sorry but look for this:
do you have an empty file /sys/block/sda/sda3/whole_disk ? or /sys/block/sdc/sdc3/whole_disk?
If yes, then we need to check why udev is not catching the attribute. If no, it might be a regression in more recent kernels. I am running an old 2.6.24 here.
Fabio
On Fri, Mar 5, 2010 at 5:20 PM, Fabio M. Di Nitto fdinitto@redhat.com wrote:
If yes, then we need to check why udev is not catching the attribute. If no, it might be a regression in more recent kernels. I am running an old 2.6.24 here.
Fabio
Hi,
Yes both files exist and are empty here :-)
Patrick
On 03/05/2010 12:48 PM, Patrick Ale wrote:
On Fri, Mar 5, 2010 at 5:20 PM, Fabio M. Di Nitto fdinitto@redhat.com wrote:
If yes, then we need to check why udev is not catching the attribute. If no, it might be a regression in more recent kernels. I am running an old 2.6.24 here.
Fabio
Hi,
Yes both files exist and are empty here :-)
So, I'm very suspicious that the duplicate UUID is not your problem.
~spot
On Fri, Mar 5, 2010 at 7:29 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
On 03/05/2010 12:48 PM, Patrick Ale wrote:
On Fri, Mar 5, 2010 at 5:20 PM, Fabio M. Di Nitto fdinitto@redhat.com wrote:
If yes, then we need to check why udev is not catching the attribute. If no, it might be a regression in more recent kernels. I am running an old 2.6.24 here.
Fabio
Hi,
Yes both files exist and are empty here :-)
So, I'm very suspicious that the duplicate UUID is not your problem.
It is not, what we were discussing on IRC seems to be it. I did a blkid, copy/pasted the UUID of sdc1 into silo.conf and it boots just fine
Patrick
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Good morning!
Before filing a bug, I want to see what you have to say :)
I did an FC12 installation on my Ultra 5 and noticed something weird.
[root@medusa /]# blkid /dev/sda1: UUID="5227bdcc-de97-4a1a-8d01-49e06e882771" TYPE="ext3" /dev/sda3: UUID="5227bdcc-de97-4a1a-8d01-49e06e882771" TYPE="ext3" /dev/sdb1: UUID="90a9428f-72c6-ae35-e4e6-37e93e5dd7b5" TYPE="linux_raid_member" /dev/sdc1: UUID="7fd60fe3-8252-40e8-8ec4-8790287eb8e8" TYPE="ext4" /dev/sdc2: UUID="e07227d5-8519-44b7-a046-75406f2598ce" TYPE="swap" /dev/sdc3: UUID="7fd60fe3-8252-40e8-8ec4-8790287eb8e8" TYPE="ext4" /dev/sdc4: UUID="01d42e64-932b-4abb-98f0-5c78807e8b06" TYPE="ext4" /dev/sdc5: UUID="8e47e08c-4918-452d-a266-d26d8185c106" TYPE="ext4"
Note how all first slices and the third slices on both my ATA and SATA disk are duplicates. This becomes very problamatic during booting.
silo.conf by default after installation uses root=UUID="7fd60fe3-8252-40e8-8ec4-8790287eb8e8". The kernel panics, mentions "you have to specify a filesystem" and sleeps forever.
Any chance you can remove "quiet" from the boot command line and see if we get more details here? I'm not entirely convinced that this is to blame.
~spot
On Fri, Mar 5, 2010 at 4:32 PM, Tom "spot" Callaway tcallawa@redhat.com wrote:
On 03/04/2010 04:34 AM, Patrick Ale wrote:
Any chance you can remove "quiet" from the boot command line and see if we get more details here? I'm not entirely convinced that this is to blame.
Sure thing, weekend starts for me in 15 minutes :-) I'll let you know what's happening when I arrive home.
~spot
Patrick