Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 192272 - mkninitrd fails to create bootable image on FC5 with Mylex hw RAID controller
mkninitrd fails to create bootable image on FC5 with Mylex hw RAID controller
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-05-18 14:42 EDT by Leon Flaks
Modified: 2008-05-06 11:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 11:55:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
init created by mkinitrd versin 5.0.39-1 (1.33 KB, text/plain)
2006-05-18 14:42 EDT, Leon Flaks
no flags Details
/etc/fstab file (1.13 KB, text/plain)
2006-05-18 14:49 EDT, Leon Flaks
no flags Details
/etc/modprobe.conf file (135 bytes, text/plain)
2006-05-18 14:51 EDT, Leon Flaks
no flags Details

  None (edit)
Description Leon Flaks 2006-05-18 14:42:35 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)

How reproducible:

Steps to Reproduce:
1.install kernel module or run mkinitrd manually
2.reboot into newly installed kernel

Actual results:
system never boots with kernel panic

Expected results:
boot into new kernel

Additional info:

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
and eventually 
kernel panic

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
both fail
Comment 1 Leon Flaks 2006-05-18 14:42:35 EDT
Created attachment 129472 [details]
init created by mkinitrd versin 5.0.39-1
Comment 2 Leon Flaks 2006-05-18 14:49:51 EDT
Created attachment 129474 [details]
/etc/fstab file
Comment 3 Leon Flaks 2006-05-18 14:51:53 EDT
Created attachment 129475 [details]
/etc/modprobe.conf file
Comment 4 Yuri Gelfand 2006-06-01 10:01:38 EDT
Looks to be same issue as #188197, though still no solution there either.
Comment 5 Leon Flaks 2006-06-01 16:38:07 EDT
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
still have: 
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!
Comment 6 Leon Flaks 2006-07-31 15:11:06 EDT
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
boot partitions.
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:
with line 
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 !!
Comment 7 Bug Zapper 2008-04-03 22:55:16 EDT
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
the change.

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
Comment 8 Bug Zapper 2008-05-06 11:55:20 EDT
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.

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