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: always 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
Created attachment 129472 [details] init created by mkinitrd versin 5.0.39-1
Created attachment 129474 [details] /etc/fstab file
Created attachment 129475 [details] /etc/modprobe.conf file
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 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!
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: root=/dev/rd/c0d0p3 with line append="root=/dev/rd/c0d0p3" 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. http://fedoraproject.org/wiki/LifeCycle/EOL 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: 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. 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.