Bug 349161

Created attachment 235311 [details]
My modified inird init script.

Created attachment 235421 [details]
Broken initrd image (requested from a user on IRC)

We can't seem to reproduce this on nvidia or intel dmraid hardware with rawhide.
Did you do anything strange with respect to partitioning/disks during the
installation? 

Nothing strange in my view. First Partition is a Windows NTFS. After that comes
/boot with ext2, swap, / with xfs and finally a big NTFS partition.

I just finished doing a fresh install with todays boot.iso (x86_64) from rawhide
and rawhide installation source (http://download.fedora.redhat.com). 

There is no difference. After a successfull installation the system cannot mount
the root filesystem and stops with a kernel panic. I've extracted again the init
script of the generated initrd image and the command "dm partadd ..." is still
missing. 

So from the rescue system I only changed this:
dm create isw_cbffadjbhf_Volume0 0 1250275840 striped 2 256 8:0 0 8:16 0

To:
dm create isw_cbffadjbhf_Volume0 0 1250275840 striped 2 256 8:0 0 8:16 0
dm partadd isw_cbffadjbhf_Volume0

After packing it together to a new initrd image the system boots up correctly
and is able to mount the root filesystem. It's that simple! ;)

Created attachment 236591 [details]
Some files in this archive: lspci, fdisk, anaconda-ks.cfg

Well, this breaks installs, and thus needs to be investigated as a potential
release-blocker. Adding to F8Blocker.

I could not reproduce with /boot ext3, swap, / xfs (nvidia dmraid).  Will try
again with NTFS being involved.

I've tried to install on ext3 as root filesystem, but the same problems occurs.

Hi folks:

I have an Intel DP35DP motherboard with the ICH9R chipset / Intel Matrix storage. 

With FC8 Test 3 it doesn't even detect the RAID 1 (fakeraid I know) array in a
way that one can access it.

dmraid -r displays the raid array, but it isn't accessible as a device anywhere
else in /dev.

Interestingly, I don't seem to get much further in FC7 - I get as far as
creating and formatting partitions, but then the installer dies and claims that
the ext3 partition is likely not formatted. On closer inspection the detail in
/var/log/messages seems to indicate an incorrect journal node.

I've spent the last day trying to build a new x86_64 live CD from i386 using
revisor and I'm about to pull my hair out (seems like that doesn't really work
properly either) - attempting to build an FC7 with updates that might be able to
actually install on the RAID.

Do you need more detail?

I'd be glad to help, if someone could point me in the direction of what else I
should try.

Thanks,
Rolf.

Just to clarify: 

Thomas seems to be able to install and reboot on FC8T3, I can't even get the
install done off the live DVD (x86_64) for FC8T3/FC7...

Created attachment 240711 [details]
Anaconda dump of RAID device initialisation during install of FC8T3

Tried to reproduce this with a promise raid controller and windows installed on
the first partition of the RAID 0, using rawhide-20071027.  (I couldn't get
windows to isntall on my ISW box for unrelated reasons.)  No difference; I still
can't reproduce it.  The resulting install boots just fine.

Due to lack of reproducing on a number of machines with dmraid, dropping from
the blocker list

I believe I am hitting the same problem (install works but the first boot fails 
with can't find `/dev/root') in RHEL5.1 although I have a slightly different 
workaround in the `initrd'.  I am using an Intel iMSM controller with 2 disks 
setup as RAID1.

After the installation the `initrd' contains the command:

dmraid -ay -i -p "isw_cdjgdjgaeg_Volume0"

This command fails with the error:

No RAID sets and with names: "isw_cdjgdjgaeg_Volume0"

Changing the `initrd' command to:

dmraid -ay -i -p "isw_cdjgdjgaeg"

works and the system now boots properly.  The problem seems to be that `dmraid' 
can find the group superset, `isw_cdjgdjgaeg', but it can't find the specific 
subset, `isw_cdjgdjgaeg_Volume0'.  I don't know which is the real problem, 
`dmraid' not being able to find the subset name or `initrd' not using the 
superset name.

Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

It looks the same problem happens with RHEL5 (5.1 and 5.2 beta). See ticket
#1825896 on RHN Support.

I have a server using a Intel S5000VSA SATAR motherboard and three SATA hard
disks configured as a RAID0 array. RHEL 5.0 installs fine, both 32 ad x86_64,
but 5.1 and 5.2 beta don't boot after install, although rescue mode works fine.

If I install RHEL5.0 and then update the kernel via RHN, the system can't boot
anynore, showing the same panic as RHEL 5.1/5.2 fresh installs.

After the update, I checked the contents of initrd before and after the update.
I found I could fix it adding the following lines to the initrd init script:

rmparts sdc
rmparts sdb
rmparts sda
dm create ddf1_4c5349202020202080862682000000003547905e00000a28 0 2923825152
striped 3 128 8:0 0 8:16 0 8:32 0
dm partadd ddf1_4c5349202020202080862682000000003547905e00000a28 

My RAID controller us identifyed by lspci as "Intel 631xESB/632xESB/ SATA
Storage Controller" 

Updated my server to RHEL5.2 and had again to fix the initrd. See bug #446284 
and Service Request 1825896.

Can the original poster provide information as to whether he encounters problems
in F9?

Everybody else should open new bugs specific to his problem, especially the RHEL
bugs - the code in RHEL 5 and Fedora 8 does not closely correspond.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.