Bug 238380 - Kernel pannic on first boot of fc7 test 4 after install of i386
Kernel pannic on first boot of fc7 test 4 after install of i386
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
9
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
David Lawrence
:
Depends On:
Blocks: FC7Blocker
  Show dependency treegraph
 
Reported: 2007-04-29 20:46 EDT by Andrew C. Moore
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-07 20:33:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
initrd from the functioning install (default kernel) (2.77 MB, application/octet-stream)
2007-04-30 17:11 EDT, Andrew C. Moore
no flags Details
initrd from the nonfunctioning install (crash on first boot) (2.77 MB, application/octet-stream)
2007-04-30 17:22 EDT, Andrew C. Moore
no flags Details
Another initrd from a broken system. (2.80 MB, application/octet-stream)
2007-05-28 07:37 EDT, Huw Pryce
no flags Details

  None (edit)
Description Andrew C. Moore 2007-04-29 20:46:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.10) Gecko/20070313 Fedora/1.5.0.10-5.fc6 Firefox/1.5.0.10

Description of problem:
I used the rawhide i386 test version 4 live disk to try and install FC7 onto a partition (sda3) of my hd. The live disk ran properly and the the install went normally until I rebooted. At that point the system locked up during the first boot and was unbootable. Even worse, the box was totally nonresponsive and I couldn't shut the system down without literally pulling the plug on the box. The error messages were as follows:
...
mount: could not find file system '/dev/root'
setuproot: error mounting /proc. No such file or directory
setuproot: error mounting /sys: No such file of directory
switch root: mount failed: no such file or directly
kernel pannic - not syncing: attemtped to kill init.

I've been able to reproduce the problem everytime whether I chose any of the three live disk boot options: run from disk, load image into ram and run from ram (I've got 2gb of ram), or run from disk and verify image. Oddly, the problem seems to be caused by setting a specific hostname on the network options screen of the install process. If I leave the name set to the default (localhost.localdomain), then everything loads properly. I've wiped the partition and tried to repoduce the result and it occurs everytime. Additionally the default setting for the hostname worked perfectly everytime.

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


How reproducible:
Always


Steps to Reproduce:
1.boot live disk and run anaconda (install to hd)
2.change the host name during the install process
3.reboot

Actual Results:
...
mount: could not find file system '/dev/root'
setuproot: error mounting /proc. No such file or directory
setuproot: error mounting /sys: No such file of directory
switch root: mount failed: no such file or directly
kernel pannic - not syncing: attemtped to kill init.

machine locks and won't respond even to the soft power or softreset case buttons
caps lock and scroll lock indicators blink until the box is rebooted

Expected Results:
FC7 test 4 firstboot

Additional info:
Comment 1 Jeremy Katz 2007-04-30 15:17:32 EDT
Can you attach the initrd from the installed system?  (either boot into rescue
mode or to the livecd and grab it)
Comment 2 Andrew C. Moore 2007-04-30 16:38:08 EDT
(In reply to comment #1)
> Can you attach the initrd from the installed system?  (either boot into rescue
> mode or to the livecd and grab it)

No problem. Give me about 30 min and I'll get to it and shoot it over to you.
Unless I'mm missing something, I should be able to just mount the fc7 partition
from my fc6 x64 partition and then grab the file. While I'm at it, do you want
anything else?
Comment 3 Andrew C. Moore 2007-04-30 17:11:11 EDT
Created attachment 153826 [details]
initrd from the functioning install (default kernel)

Here's the initrd from the functional boot. I just restalled the box from the
live disk and let it crash. It's initrd will be in the next attachment. FWIW -
I just included the working initrd for comparisison's sake.
Comment 4 Andrew C. Moore 2007-04-30 17:22:15 EDT
Created attachment 153828 [details]
initrd from the nonfunctioning install (crash on first boot)

Here's the initrd from the same partition after I reformated and reinstalled. I
grabbed this from the hd after the install and before I rebooted. If you need
any of the post crash logs, let me know and I'll remount the partition and send
it over to you. For now, I'll leave that partition in the non-functioning state
just in case you need some other files. 

FWIW - The box has the following hardware: AMDx2 5600+, 2gb ddr2 ram, eVGA
nvidia 7600 GT and an eVGA nforce 590 SLI MCP mobo with the latest bios (P34).
I've got FC6 x64, Ubuntu Fiesty Fawn x64, and XP sp2 installed on different
partitions. I've previously run FC6 i386 and the 32bit version of Ubuntu Edgy
fit without incident.
Comment 5 Ra P. 2007-05-19 09:42:59 EDT
I am having the exact same error, with very similar hardware (an x2 4600, 1gb
DDR2, 7900GT and an Asus nForce 500 SLI mobo), dual booting with Win XP. I did
not do a fresh install, however, I upgraded from FC6. It only happens with the
2.6.21 kernel, the 2.6.20 I have left over from FC6 boots perfectly which makes
me think this is something to do with the kernel. I tried compiling the 2.6.21
vanilla kernel and experienced the exact same problem. Would you like my initrd
as well?
Comment 6 Jeremy Katz 2007-05-21 18:28:11 EDT
The initrds are identical here.  I suspect this is timing related with the
driver loading and the drives being detected.  Does it still happen with the
current rawhide live images?
Comment 7 Andrew C. Moore 2007-05-22 21:20:04 EDT
I downloaded the latest Rawhide image I could find
(rawhide-20070517-i386-Live.iso), checked the sha1sum, burned it to disc,
verified the media, luanched the live disk, and ran through a clean install on
my sda3 partition. In short, it's still a problem. It looks like you've started
to pull out a lot of the debugging stubs as the documentation level is a little
less with the latest image but I'm still getting a kernel panic on the firstboot
if I try and manually set the host name. I verified that the install did work as
expected with the automatic host name. As I can get it to install by using the
default selection on the host name (localhost), it's more of an annoyance than
anything else but I'm still curious as to what's going on. My main partition is
still FC6 x64 so I can do whatever you need to the i386 test partition but I'd
like to get that partition set asap. Let me know if you need anything else and
I'll give it a go. 
Comment 8 Bruno Wolff III 2007-05-27 20:44:48 EDT
I am seeing this on the rc2 DVD for i386. I am not sure the root cause is the
same though.
I get a warning before the /dev/root problem about not being able to find
/dev/md2 to check the swapfs to see if this is a resume.
Also of note is this short excerpt from my install log:
Installing kernel - 2.6.21-1.3194.fc7.i686
cp: cannot stat `/sbin/mdadm': No such file or directory
Installing libraw1394 - 1.2.1-7.fc7.i386
Comment 9 Huw Pryce 2007-05-28 07:37:51 EDT
Created attachment 155539 [details]
Another initrd from a broken system.

The initrd from Fedora 7 RC2 which panics on boot.
Comment 10 Andrew C. Moore 2007-05-29 00:02:53 EDT
I pulled down the Fedora-7-Live-i386-RC2.iso via BitTorrent and this time
everything worked as expected. I'm not sure what the change was from the 5-20
spin to the RC2 spin, but for some reason it fixed the problem for me. I'll pull
down the final version on the 31rst to make sure it still works but it looks
like the latest spin fixed it for me.
Comment 11 Bruno Wolff III 2007-05-29 01:09:06 EDT
I want to add that I think I saw the same thing on a second machine I had when
doing a test install with test4. Unfortunately the machine was left in a state
where I couldn't easily retest the install. Both of the machines I saw it on
where dual processor machines. The one with a problem with RC2 is a dual Athlon
and the one with a problem with test4 is a dual PII.
Comment 12 Andrew C. Moore 2007-06-02 03:00:00 EDT
The final release live disk also worked fine.
Comment 13 Huw Pryce 2007-06-02 05:54:24 EDT
I am still seeing this, with the exact same error message on the release.
Perhaps I am having a different problem but the error message is the same.
Unlike with RC2 this happens whether I change the hostname or not (it did work
with an unchanged hostname in RC2).
Comment 14 Bruno Wolff III 2007-06-05 04:39:23 EDT
I repeated the failure with the released version of F7 doing a full, fresh
install of the DVD iso.
Comment 15 Bruno Wolff III 2007-06-05 16:25:56 EDT
I don't know if this will help narrow things down, but since I noticed these
seem to be all be SMP systems I tried booting with maxcpus=0 and maxcpus=1.
maxcpus=0 resulted in new errors ocurring. maxcpus=1 resulted in the the same
problem ocurring as when not using that boot option.
Comment 16 Bruno Wolff III 2007-06-06 22:31:54 EDT
I did a half a dozen or so installs today to try to narrow this problem down.
It looks like it might be some package that is causing this problem (at least in
my case). But it isn't any one obvious to me and I don't know which one it is.
When I don't relatively minimal installs I don't see the problem. When I do near
everything installs (from the DVD) I do have the problem. Installing just
checking the three boxes and not doing any customization leads to an install
that works. Doing a custom install and selecting everything (including all
optional packages) for all categories except legacy software, virtualization and
the various languages results in an install that doesn't work (i.e. the first
boot has a kernel panic).
Doing this testing is pretty time consuming. So just randomly adding and
removing chunks of packages to try to narrow things down further doesn't seem
worthwhile. If you have some suggestions on what package installs might affect
things before the root pivot (I wouldn't expect there to be many of these) I can
do some further tests.
Is there some way to get a dump of the messages from before the root pivot to
persistant media? Once the kernel panics there doesn't seem to be anything I can do.
Comment 17 Bruno Wolff III 2007-06-11 00:40:56 EDT
I did some more test installs and have narrowed it down to something brought in
by selecting optional packages in 'Base' other than compatibility software or
virtualization. Over the next week or two, I should be able to get it down which
package if it is caused by a single package.
Comment 18 Bruno Wolff III 2007-06-11 15:59:47 EDT
I narrowed the problem down to syslog-ng and/or eventlog causing a problem with
the first boot after an install. Since I am not sure if the cause in my case is
the same as that for the person that opened this bug, I opened a new bug
(243772) under syslon-ng (and added a pointer back here just in case).
Comment 19 Douglas E. Warner 2008-02-22 22:39:24 EST
Is this still a problem that needs to be tracked down?
Comment 20 Bruno Wolff III 2008-02-23 09:48:51 EST
I am not the reporter, but my problem was covered by another bug (243772) which
you also asked about. I see no reason to keep this one open on my account.
Comment 21 Bug Zapper 2008-05-13 22:50:02 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Brennan Ashton 2008-06-07 20:33:26 EDT
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

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