Bug 316911 - kernel panic vmlinux-2.6.22.9-91.fc7, can not upgrade from 2.6.22.5-73 on restored filesystem
Summary: kernel panic vmlinux-2.6.22.9-91.fc7, can not upgrade from 2.6.22.5-73 on res...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-03 14:27 UTC by Bill C. Riemers
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-10-04 00:16:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bill C. Riemers 2007-10-03 14:27:59 UTC
Description of problem:


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

When attempting to boot from vmlinux-2.6.22.9-91.fc7, the kernel fails to find
root and panics.  The machine boots normally from vmlinux-2.6.22.5-76.fc7.  The
only thing that makes this a little unique is that I restored this system from
backup.  The backed up initrd did not work, so I created a new one by installing
a small Fedora install, and then using the same initrd to point to the regular
install.

My root is on a LVM logical volume on RAID device /dev/md2.  I might have
thought this was related to the problem, but it appears to find the logical
volume group, and the same kernel works on my DELL machine with virtually the
same configuration.

mount could not find filesystem '/dev/root'
Setting up other filesystems
Setting up new root fs2
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init
umounting old /dev
umounting old /proc
umounting old /sys
switchroot: mount failed. No such file or directory
Booting has failed.
Kernel panic - not syncing: Attempt to kill init!



How reproducible:

Everytime I boot.

Steps to Reproduce:
1. Try rebooting my machine after upgrading from 2.6.22.5-76 to 2.6.22.9-91
2.
3.
  
Actual results:

kernel panic

Expected results:

boots normally

Additional info:

Contents of grub.conf:

default=0
timeout=30
splashimage=(hd0,1)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.22.9-91.fc7)
        root (hd0,1)
        kernel /vmlinuz-2.6.22.9-91.fc7 ro root=/dev/h6410/Fedora7
        initrd /initrd-2.6.22.9-91.fc7.img
title Fedora (2.6.22.5-76.fc7)
        root (hd0,1)
        kernel /vmlinuz-2.6.22.5-76.fc7 ro root=/dev/h6410/Fedora7
        initrd /initrd-2.6.22.5-76.fc7.img
title Windows XP Pro
        rootnoverify (hd0,0)
        chainloader +1
title Small Fedora (2.6.22.5-76.fc7)
        root (hd0,1)
        kernel /vmlinuz-2.6.22.5-76.fc7 ro root=/dev/h6410/Fedora7small
        initrd /initrd-2.6.22.5-76.fc7.img
title Rescue
        root (hd0,1)
        kernel /vmlinuz
        initrd /initrd.img

Comment 1 Bill C. Riemers 2007-10-03 14:43:48 UTC
Note:  In the original system my root filesystem was /dev/sys/Fedora7.  When I
restored it from backup, I placed it on raid device /dev/md2 as /dev/h6410/Fedora7.



Comment 2 Chuck Ebbert 2007-10-03 16:18:21 UTC
Can you compare the working and non-working initrds? The below link has some
directions:

https://fedoraproject.org/wiki/KernelBugTriage#head-22000aaecbb847220ed786f4b17129fd8fc79668


Comment 3 Bill C. Riemers 2007-10-03 17:01:14 UTC
I compared, and it turns out the problem is /etc/mdadm.conf was missing from the
initrd-2.6.22.9-91.fc7.img file.   I copied mdadm.conf from the old initrd to
/etc in my root filesystem, and then rebuild the now initrd.  That solved the
probem.

So it appears the problem is that the logic for finding the root partition in
the initrd is not correct.  Even though /dev/md2 was activated without having
mdm.conf, and the logical volume was found, it could not find the root partition
without access to an mdm.conf file.

Bill


Comment 4 Chuck Ebbert 2007-10-04 00:16:06 UTC
Closing as notabug, it's not really posible to reconstruct exactly what happened.

Comment 5 Bill C. Riemers 2007-10-04 13:53:04 UTC
I believe that should be a "WORKSFORME".  As it definitely is a bug, but it
works for you, so you can not reproduce it to try and fix the problem.


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