Red Hat Bugzilla – Bug 192272
mkninitrd fails to create bootable image on FC5 with Mylex hw RAID controller
Last modified: 2008-05-06 11:55:21 EDT
Description of problem: minitrd fails to make bootable image on FC5 with mylex
RAID controller, cousing kernel panic
Version-Release number of selected component (if applicable):
mkinitrd-5.0.32-1 and mkinitrd-5.0.39-1 (from devel tree)
Steps to Reproduce:
1.install kernel module or run mkinitrd manually
2.reboot into newly installed kernel
system never boots with kernel panic
boot into new kernel
I have 2 issues here - first, the module DAC960 is never picked up from
modprobe.conf, so I always have to manyally tell mkinitrd to add it with comand
/sbin/mkinitrd --preload=DAC960 --omit-scsi-modules initrd-$1.img $1 ;where $1
is the kernel version. That is going on since RH9 or so. But now with FC5 even
this trick doesn't help any more. After upgrading to FC5 from FC4 I can boot the
system only into kernel which was left from FC4. Here is what I see with image
created by mkinitrd-5.32-1:
after loading all three modules (DAC960.ko, jbd.ko and ext3.ko) I have:
trying to resume from /dev/rd/c0d0p2
Unable to access resume device (/dev/rd/c0d0p2)
Creating root device
Mounting root filesystem
Mount could not find filesystem '/dev/root'
Setting up other filesystems
Setting up new root fs
Setuproot: moving /dev/faied: No such file or directory
no fstab.sys, mounting internal defaults
Setuproot: error mounting /proc: No such file or directory
I tried new version from develepment tree - mkinitrd-5.0.39-1
I see only one difference - no complain in resume statement - it just said
no suspend signature on swap, not resuming, the rest is identical (still mount:
couldn't find filesystem '/dev/root'
I am attaching init file from image (after unzipping and cpio).It was created by
the version 5.0.39-1.
From this file looks like command mkblkdevs succeded, but mkrootdev did not.
fstab and modprobe.conf will be attached separately. In version 5.0.32-1 they
Created attachment 129472 [details]
init created by mkinitrd versin 5.0.39-1
Created attachment 129474 [details]
Created attachment 129475 [details]
Looks to be same issue as #188197, though still no solution there either.
I tried to add line
mknod /dev/rd/c0d0p3 b 48 3
as was suggested in #188197. It did not work - now I have: 'failed to create
/dev/rd/c0d0p3: file exists'. So, looks like it was created just fine. Then I
Mounting root file system
Mount: could not find filesystem 'dev/root'
All this was done with mkinitrd 5.0.39-1
Original FC5 initrd (5.0.32-1) is not complainig about existing file (I guess
nash did not make it!), but the rest is the same.
I see 2 problems here - one wich can be solve by making nodes or by using
5.0.39-1 version of mkinitrd. But I still have an issue with mounting root file
system after the node is created. The line 'mkrootdev /dev/root' in init file
does not work!
I found a solution for this issue. It turned out to be a combination of
different problems. I am using lilo on this system - grub was never able to find
First I upgaded mkinitrd to version mkinitrd-5.0.39-1 from development tree. It
is not the latest version available as of today, but latest version (5.1.2-1)
requires other packages from rawhide to be updated. This step helped to solve
issue mentioned in comment #4.
Then, after reading comments from bug #197701, I replaced a line in lilo.conf:
That turned out to be the key!
I still need to run mkinitrd manually forcing DAC960 module to be included.
Many thanks to Yuri Gelfand and Jan Kratochvil !!
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.