Bug 238380

Can you attach the initrd from the installed system?  (either boot into rescue
mode or to the livecd and grab it)

(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?

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.

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.

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?

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?

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. 

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

Created attachment 155539 [details]
Another initrd from a broken system.

The initrd from Fedora 7 RC2 which panics on boot.

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.

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.

The final release live disk also worked fine.

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).

I repeated the failure with the released version of F7 doing a full, fresh
install of the DVD iso.

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.

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.

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.

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).

Is this still a problem that needs to be tracked down?

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.

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

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.