Bug 206796 - Kernel panic when booting kernel 2.6.17-1.2630.fc6
Summary: Kernel panic when booting kernel 2.6.17-1.2630.fc6
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
(Show other bugs)
Version: 6
Hardware: i386 Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-16 19:32 UTC by Patrick Nell
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-24 19:45:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Patrick Nell 2006-09-16 19:32:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20060728 Firefox/

Description of problem:
After installing FC6 on my laptop I always get this kernel panic. I'm running 4 different OSes and I'm booting with grub in MBR.

/boot/grub/menu.lst (from ubuntu):
title Fedora Core (2.6.17-1.2630.fc6)
	root (hd0,10)
	kernel /boot/vmlinuz-2.6.17-1.2630.fc6 ro root=LABEL=/ rhgb quiet
	initrd /boot/initrd-2.6.17-1.2630.fc6.img

Version-Release number of selected component (if applicable):
Kernel 2.6.17-1.2630.fc6

How reproducible:

Steps to Reproduce:
1. fresh install ot fc6 (from CD)
2. boot fc6

Actual Results:
Unabel to accesss resume device (Label=SWAP-hda7)
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: 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!

Expected Results:
Kernel should boot!

Additional info:
/dev/sda1 - windows
/dev/sda6 - ubuntu
/dev/sda9 - mandriva
/dev/sda11 - fc6

Comment 1 Kirk C Aune 2006-09-16 21:52:50 UTC
I believe my problems are related to this particular problem and suggest that
the problem relates to an difference in writing order in the new mkinitrd for
output to the init file in the "*.img" file.

My setup uses a /boot directory on /dev/hda to point where booting kernels
reside.   My systems happen to reside on a sata drive, /dev/sdb.   Prior to the
most recent changes in mkinitrd, I was able to boot my configuration without
problem.  This occurred about the time nash-5.1.9 was superceded with a new one.
  Since that time I have been struggling to determine why my root file system
was not found leading to kernel panic.   I finally found out how to inspect the
content of initrd-2.6.18-rc7.img compared to my last working boot with
initrd-2.6.18-rc5.img.    What I found was that IF in the "init" file of the
uncompressed tree of initrd-2.6.18-rc7.img, I moved the reference:

echo "Loading scsi_transport_spi.ko module"
insmod /lib/scsi_transport_spi.ko

ahead of, rather than after (as written by the newer mkinitrd)

echo "Loading libata.ko module"
insmod /lib/libata.ko 
echo "Loading sata_via.ko module"
insmod /lib/sata_via.ko 
(my modules necessary to activate the sata drives)

The boot process completes like a champ.   More importantly, and relevant to fc6
stock kernels with their *.img files, when I simply make the same reordering of
the modules inside of the "init" file from unzipping and uncpioing the *.img
file and then reassembling the file and trying a boot of the stock fc6 latest
yum supplied kernel, low and behold the thing boots without trouble.   ORDER of
modules loading is apparently important here.   I am of insufficient knowledge
to know why it is important and someone better equipped will figure it out and
make the correction, I assume.

I suggest you examine whether module reference order is different in the newer
versions of the *.img file compared to your last working *.img file and see if
that solves the problem.  If it does, let us collectively hope that the powers
that be see the problem in mkinitrd.

Kirk C. Aune 

Comment 2 Kirk C Aune 2006-09-23 15:18:03 UTC
I found additionally, that jbd.ko and ext3.ko must be installed AFTER the

SOooo ..., I solve all of my problems, whether I boot a custom kernel or the FC6
kernel shipped with development by unwrapping the *.img file; editing the init
file therein to reorder the scsi modules and placing the above referenced
modules AFTER the scsi modules; reassembling the *.img file and booting.   No
more kernel panic.

Hence, it is a simple ordering problem with the output which creates the "init"
file inside of the *.img file built by mkinitrd.   Why that is the case is up to
those more savy than me!

Comment 3 Peter Jones 2006-09-27 22:02:33 UTC
What version of mkinitrd were you using when you saw this, and is it still
happening with 5.1.17-1 or newer?

Comment 4 Kirk C Aune 2006-09-27 23:50:21 UTC
The panic did not occur with nash-5.1.9.  I noticed it occuring with nash-5.1.15
after I had diagnosed the problem as being order inside of the "init" file.  I
currently have mkinitrd-5.1.17-1 on my machine with the latest yum, although I
don't know if that came after or before the latest kernel (2.6.18-1.2693.fc6)
which did require the unwrap, editing of init, and rebuild of the
initrd.2.6.18-1.2693.fc6.img file.   I can only assume that 5.1.17 was used to
make the latter file, so my guess would be yes that mkinitrd was used and no,
that did not fix the problem.

I did just re-read my note above to indicate the slight peculiarity in booting,
but since it did work previously, it was not that wierd.   Is is necessary to
add that the module is via_sata.ko??   I later discovered that it was important
that the ext3 and jbd modules also had to come after the scsi modules.

Comment 5 Patrick Nell 2006-10-01 15:39:08 UTC
(In reply to comment #3)
> What version of mkinitrd were you using when you saw this, and is it still
> happening with 5.1.17-1 or newer?

I would love to provide the requested information but I'm not capable, I'm just
a simple user. Please tell me how to optain this information and I'll provide it!

The only thing I can tell you is that I tried twice to install fc6 always with
the same result - the system was not booting into fedora. 

The last version was test 3 which I downloaded via torrent on September 15 - I
can provide the checksums of the CDs if this will help. After installing my
system never booted so I suppose the mkinitrd should be the one included in test  3.

Exactly the same error I already had with test 2 - I would like to help fix this
bug, not only to see fedora on my system! ;-))

Comment 6 Thorsten Scherf 2006-10-13 10:08:37 UTC
had the same problems. everything seems to fixed in version 5.1.19-1.

Comment 7 Patrick Nell 2006-10-20 15:05:01 UTC
(In reply to comment #3)
> What version of mkinitrd were you using when you saw this, and is it still
> happening with 5.1.17-1 or newer?

Don't know which version I'm using now - but the installation of "pre" went well
and everything's running just fine.

Comment 8 Will Woods 2007-03-24 19:45:13 UTC
Closing based on comments.

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