Bug 500322 - dmraid cannot handle disks with GPT
Summary: dmraid cannot handle disks with GPT
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-12 09:26 UTC by Winfrid Tschiedel
Modified: 2009-08-25 12:05 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-19 07:49:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Updated mkinitrd which hopefuly fixes this (44.10 KB, text/plain)
2009-05-17 13:57 UTC, Hans de Goede
no flags Details

Description Winfrid Tschiedel 2009-05-12 09:26:07 UTC
Description of problem:

please read also 464553 - Feature request for rhel-6, rhel-5.4 (?)


Version-Release number of selected component (if applicable):


How reproducible:

always


Steps to Reproduce:
1. Install fedora 11 on disk with GPT and activated dmraid

  
Actual results:

The system can be installed, but first boot fails

Expected results:

Successful firstboot


Additional info:

Should be reproduceable on any platform supporting SATA RAID (dmraid) -
I did my tests on Fujitsu Primergy rx220 ( Promise FastTrek S150 TX4 )
test cannot be done on ICH#R or ESB2 with LSI firmware (ddf1) because on those systems fedora does not boot on a dmraid controlled disk even without GPT.

My rx220 has 2 RAID0 disks -
on the first disk (RAID0, msdos partition table) I installed fedora 11 Preview.
After this I changed the second disk with parted to a disk with GPT.

Now I installed on the configuration a second Fedora 11 Preview on the 
disk with GPT. The installation finished without visible problems.

Now I tried to finish the installation of the second Fedora, but the system
did not come up. 
Doing an analysis with my first Fedora I see the following : 

/dev/sdb: pdc, "pdc_cbbgheicjb", stripe, ok, 312368928 sectors, data@ 0
/dev/sda: pdc, "pdc_djgfieghjb", stripe, ok, 312368928 sectors, data@ 0
[root@rx220 ~]# dmraid -s -c -c -c
ERROR: ddf1: both header signatures bad on /dev/sda
pdc_cbbgheicjb:312368896:128:stripe:ok:0:1:0
/dev/sdb:pdc:pdc_cbbgheicjb:stripe:ok:312368928:0
pdc_djgfieghjb:312368896:128:stripe:ok:0:1:0
/dev/sda:pdc:pdc_djgfieghjb:stripe:ok:312368928:0
[root@rx220 ~]# dmsetup table
pdc_djgfieghjbp2: 0 41943040 linear 253:0 409601
pdc_djgfieghjbp1: 0 409600 linear 253:0 1
pdc_cbbgheicjb: 0 312368896 linear 8:16 0
pdc_djgfieghjb: 0 312368896 linear 8:0 0
[root@rx220 ~]# parted /dev/mapper/pdc_cbbgheicjb 
GNU Parted 1.8.8
Using /dev/mapper/pdc_cbbgheicjb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: Linux device-mapper (dm)
Disk /dev/mapper/pdc_cbbgheicjb: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.9kB  32.2GB  32.2GB  ext3               boot 

(parted) quit         

I see with parted the partition where I installed the second Fedora 
but I cannot access it.

Comment 1 Heinz Mauelshagen 2009-05-12 10:50:37 UTC
dmraid is not going to support GPT partitioning.
Please use "kpartx -a /dev/mapper/pdc_cbbgheicjb" instead.

The referenced bz#464553 is about partitioning support in anaconda, which causes utilizing kpartx for activation.

Comment 2 Winfrid Tschiedel 2009-05-12 14:07:25 UTC
please reopen this issue -
it maybe true, that this is no dmraid problem,
nevertheless there should be no restriction on dmraid to use GPT labels,
which is important, because the max. size supported by old style partition
tables is 2 TB. 

Please assign this issue to the right product(s). 
All I expect is that I can install a linux distribution on a SATA RAID using GPT - and should not care about any commands .

Winfrid

Comment 3 Heinz Mauelshagen 2009-05-12 14:38:36 UTC
It'll be solved in anaconda/mkinitrd, hence my comment #1.

Comment 4 Hans de Goede 2009-05-12 17:19:44 UTC
Winfrid, given what Heinz said in comment #1, this is an mkinitrd bug. Bug 464553 seems to only track the anaconda part of this, and given your description (installs properly but doesn't boot), combined with the fact that mkinitrd in  Fedora atm is not using kpartx, there clearly also needs to be done some work
on the mkinitrd side of things.

I'll take care of this and provide you with an updated mkinitrd to test. In the mean time I'm re-opening this to track the mkinitrd side of this, and changing the component to match.

Comment 5 Hans de Goede 2009-05-17 13:57:46 UTC
Created attachment 344328 [details]
Updated mkinitrd which hopefuly fixes this

Winfrid,

Here is a fixed mkinitrd script can you give this a try please and see if it
fixes things?

To use this:
1) install F-11
2) boot the F-11 installer into rescue mode
3) copy this mkinitrd to /mnt/sysimage
4)
chroot /mnt/sysimage

5)
./mkinitrd -f /boot/initrd-<kernelver>.img <kernelver>

You can get the first <kernever> by using the tab key, then fill in the second
to be exactly the same as the first. After this you have a new initrd which should use kpartx

To verify this do:
zcat /boot/initrd-<kernelver>.img | cpio -i init
less init

You should now see the use of kpartx in the initscript just extracted from 
the initrd.

6) Reboot, and hopefully things work now.

Please let us know if this fixes dmraid with GPT, thanks.

Comment 6 Winfrid Tschiedel 2009-05-18 15:29:53 UTC
Hello Hans,

You did a great job - for my system ( Fujitsu Primergy rx220 with
Promise Raid TX150 ) it works. 

Next open item is to place the boot-partition on a partition >= 4
and to use the boot-sector in the boot-partition -
I know already that this does not work with grub, but I have no
experience with grub2. I would like to test this, but I need for this help 
from somebody with grub2 experience.

Have a nice evening and thanks again,

Winfrid

Comment 7 Hans de Goede 2009-05-19 07:49:24 UTC
(In reply to comment #6)
> Hello Hans,
> 
> You did a great job - for my system ( Fujitsu Primergy rx220 with
> Promise Raid TX150 ) it works. 
> 

Ok, thanks for testing, the fix in the attached mkinitrd has been commited to
mkinitrd's git tree:
http://git.fedorahosted.org/git/?p=mkinitrd;a=commitdiff;h=b625d07cb873e7c148442dd03c5b43263a20bf12

And thus will be part of the next mkinitrd release (6.0.85-1), not sure if
that will make F-11 final though.  

> Next open item is to place the boot-partition on a partition >= 4
> and to use the boot-sector in the boot-partition -
> I know already that this does not work with grub, but I have no
> experience with grub2. I would like to test this, but I need for this help 
> from somebody with grub2 experience.
> 

Hmm, this will need to be tracked in a new bug, no idea when we're going to
switch to grub2 though (it won't be soon).


Note You need to log in before you can comment on or make changes to this bug.