Bug 349161 - Missing entries in the init script of the initrd image makes the system unbootable on dmraid
Summary: Missing entries in the init script of the initrd image makes the system unboo...
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-23 18:00 UTC by Thomas Babut
Modified: 2014-09-08 11:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-09 04:59:54 UTC
Type: ---
tbabut: needinfo-

Attachments (Terms of Use)
My modified inird init script. (2.37 KB, text/plain)
2007-10-23 18:00 UTC, Thomas Babut
no flags Details
Broken initrd image (requested from a user on IRC) (3.32 MB, application/octet-stream)
2007-10-23 19:36 UTC, Thomas Babut
no flags Details
Some files in this archive: lspci, fdisk, anaconda-ks.cfg (2.84 KB, application/zip)
2007-10-24 20:10 UTC, Thomas Babut
no flags Details
Anaconda dump of RAID device initialisation during install of FC8T3 (20.07 KB, text/plain)
2007-10-27 20:16 UTC, Rolf Poser
no flags Details

Description Thomas Babut 2007-10-23 18:00:16 UTC
Description of problem:
Booting with a software raid is causing a kernel panic because of missing
entries in the init script of the initrd image.

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

How reproducible:
Since there are some parts missing in the generated init script in the initrd
image the system boot always stops with a kernel panic because not being able to
mount the root filesystem.

Steps to Reproduce:
1. Install Fedora 8 Test 3
2. Reboot the system after successfull installation
3. System is not able to mount the root filesystem causing kernel panic
Actual results:
Unable to mount root filesystem causing kernel panic

Expected results:
Mount root filesystem and boot properly

Additional info:
I've got a Gigabyte Mainboard with P35/ICH9R chipset and a Intel Matrix Raid
with two hard drives with raid level 0. Installation of Fedora 8 Test 3
completes successfully. But after rebooting the installed system I get a kernel
panic, because the root filesystem cannot be mounted:

mount: could not find filesystem '/dev/root'
setuproot: moving /dev/ failed: No such file or directory
setuprooot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

After extracting the initrd image I've modified the init script.

 rmparts sdb
 rmparts sda
 dm create isw_cbffadjbhf_Volume0 0 1250275840 striped 2 256 8:0 0 8:16 0

Add here:
 dm partadd isw_cbffadjbhf_Volume0

 echo Creating root device.

Add here:

With this modifications the system boots fine. It would be great to have this
fix get into before releasing Fedora 8 final.

I don't know if this is a bug in the mkinitrd or dmraid package, so I filed it
against the mkinitrd package.

Comment 1 Thomas Babut 2007-10-23 18:00:52 UTC
Created attachment 235311 [details]
My modified inird init script.

Comment 2 Thomas Babut 2007-10-23 19:36:58 UTC
Created attachment 235421 [details]
Broken initrd image (requested from a user on IRC)

Comment 3 Will Woods 2007-10-23 20:50:39 UTC
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

Comment 4 Thomas Babut 2007-10-24 05:15:36 UTC
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.

Comment 5 Thomas Babut 2007-10-24 20:08:49 UTC
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

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

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! ;)

Comment 6 Thomas Babut 2007-10-24 20:10:59 UTC
Created attachment 236591 [details]
Some files in this archive: lspci, fdisk, anaconda-ks.cfg

Comment 7 Will Woods 2007-10-24 20:53:23 UTC
Well, this breaks installs, and thus needs to be investigated as a potential
release-blocker. Adding to F8Blocker.

Comment 8 Jesse Keating 2007-10-25 13:03:19 UTC
I could not reproduce with /boot ext3, swap, / xfs (nvidia dmraid).  Will try
again with NTFS being involved.

Comment 9 Thomas Babut 2007-10-26 16:10:27 UTC
I've tried to install on ext3 as root filesystem, but the same problems occurs.

Comment 10 Rolf Poser 2007-10-27 19:28:54 UTC
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.


Comment 11 Rolf Poser 2007-10-27 19:32:38 UTC
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...

Comment 12 Rolf Poser 2007-10-27 20:16:30 UTC
Created attachment 240711 [details]
Anaconda dump of RAID device initialisation during install of FC8T3

Comment 13 Peter Jones 2007-10-29 22:17:44 UTC
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.

Comment 14 Jeremy Katz 2007-10-30 20:18:33 UTC
Due to lack of reproducing on a number of machines with dmraid, dropping from
the blocker list

Comment 15 Don Dugger 2007-12-07 23:35:47 UTC
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.

Comment 16 Bug Zapper 2008-04-04 14:15:03 UTC
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
(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:

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

Comment 17 Fernando Lozano 2008-05-13 21:33:18 UTC
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" 

Comment 18 Fernando Lozano 2008-05-21 22:53:09 UTC
Updated my server to RHEL5.2 and had again to fix the initrd. See bug #446284 
and Service Request 1825896.

Comment 19 Andy Lindeberg 2008-07-14 20:51:28 UTC
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.

Comment 20 Bug Zapper 2008-11-26 08:05:01 UTC
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: 

Comment 21 Bug Zapper 2009-01-09 04:59:54 UTC
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.

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