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): kernel-2.6.23-6.fc8 mkinitrd-6.0.19-1.fc8 dmraid-1.0.0.rc14-2.fc7 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. Find: 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 Find: echo Creating root device. Add here: mkblkdevs 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.
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.