Bug 224289 - panic on boot as udev starts after kernel 2.6.19-2895fc6 update
Summary: panic on boot as udev starts after kernel 2.6.19-2895fc6 update
Status: CLOSED DUPLICATE of bug 224283
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-25 02:37 UTC by Walter Neumann
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-01-26 16:04:45 UTC
Type: ---

Attachments (Terms of Use)
low-res screenshot (55.35 KB, image/jpeg)
2007-01-27 20:34 UTC, Vlado Potisk
no flags Details
log file generated by the sound config tool (46.83 KB, text/plain)
2007-02-14 23:08 UTC, steve romero
no flags Details
log file generated by the sound config tool (544 bytes, text/plain)
2007-02-14 23:09 UTC, steve romero
no flags Details

Description Walter Neumann 2007-01-25 02:37:04 UTC
Description of problem: panic on boot as udev starts after kernel 2.6.19-2895fc6

Version-Release number of selected component (if applicable):
2.6.19-1.2895.fc6 and 2.6.19-1.2895.fc6debug

How reproducible:

Steps to Reproduce:
1. Boot the 2.6.19-1.2895.fc6 kernel. Previous kernel (2.6.18-1.2868.fc6) boots

Actual results:
Kernel panic, apparantly as udev loads. 

Expected results: clean boot.

Additional info:

Machine is a dual core Satellite M115-S3094 laptop. Since the panic happens
before syslog starts, nothing is logged and I only see the final screen of the
panic. It appears to be triggered by udev loading some module but I can't be
sure. I'd be glad of advice how to better debug this. The 2.6.19-1.2895.fc6debug
kernel gives the same result.

Comment 1 Chuck Ebbert 2007-01-25 18:55:59 UTC
Take a picture of the screen using a digital camera and post that as an
attachment.  (Try to cut down on the picture resolution if you can --
we don't need to see every speck of dust on the screen.)

Comment 2 Michael Smotritsky 2007-01-26 12:51:11 UTC
I have the same problem on dual emt64 IBM blades...I'm not sure about udev 
though.. I my case initrd seems unable to find/mount lvm root partition... It 
also can not see /dev/lovgroup/swap.  Is there a grub/initrd option to 
execute /linuxrc step by step, so I can pinpoint the problem? I'm using remote 
control on my blades and console output runs away from me...Then I can post it 

Comment 3 steve romero 2007-01-26 15:46:49 UTC
You may want to take a look at bug 224283.  This is exactly the same problem
that I'm having and I'm also using a Toshiba M115 laptop but the S3144 model.  I
was able to find a work around to get it to boot, which is really only useful
for gathering log files I don't think that you would want to try and do anything
with the system in that state.

From what I have been able to gather, and this is just a swag on my part, it
seems that the crash occurs while trying to initilize the sound system (alsa). 
I've seen a comment on one of the mailing list that indicated some have had
success with creating and installing the alsa 1.0.14 rc2 kernel drivers.  But
I've had no success in creating an rpm of that driver yet.

Comment 4 Walter Neumann 2007-01-26 16:04:45 UTC
Indeed the same bug as on my wife's M115-S3094 laptop. I've marked this as a
duplicate of <a
href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224289"> bug 224283</a>

*** This bug has been marked as a duplicate of 224283 ***

Comment 5 Michael Smotritsky 2007-01-26 17:15:15 UTC
I'm not sure if my problem is the same is yours...I have a prob with servers 
and there is no sound card there...In my case system can't find/mount a root 
partition... I'd say it has to do with lvm2...my root partition is in the 
logical volume...
Just found something that looks like mine:

Comment 6 Michael Smotritsky 2007-01-26 19:35:43 UTC
I've fixed my problem by recompiling initrd:

mv initrd-2.6.19-1.2895.fc6.img initrd-2.6.19-1.2895.fc6.img.orig
mkinitrd --force-lvm-probe --with=ext3 /boot/initrd-2.6.19-1.2895.fc6.img 

But i'm sure it won't fix yours...

Try to yum update again, I've noticed new sound modules and a new deviceMapper 
in the updates 

Comment 7 Vlado Potisk 2007-01-27 20:31:54 UTC
I'd like to thank the author of the comment #6. His approach solved my problem.

Here is the report: the root partition is on a a LV created on a software RAID1
array built from 2 SATA disks on Intel Celeron D desktop system with Intel 945
chipset. The 2.6.18 kernel is fine, but 2.6.19 doesn't boot. The screenshot follows.

Comment 8 Vlado Potisk 2007-01-27 20:34:38 UTC
Created attachment 146750 [details]
low-res screenshot

Comment 9 steve romero 2007-02-14 23:08:27 UTC
Created attachment 148089 [details]
log file generated by the sound config tool

Comment 10 steve romero 2007-02-14 23:09:19 UTC
Created attachment 148090 [details]
log file generated by the sound config tool

Comment 11 steve romero 2007-02-14 23:11:03 UTC
I reviewed the change log for 2.6.19-1.2911 and didn't see anything that would
lead me to believe it would resolve the issues that I'm having but updated
anyway and gave it a try.

Results are that the crash detecting the sound device is fixed, no crash on
start up.  However sound still does not work and something that I noticed with
the previous kernel, eth0 seems to load fine but it will not function.  I
continue to get 'no link present check cable'.  Even though it is connected,
wireless does work however (using dkms-ipw3945 driver from freshrpms). I haven't
gone back and tried the r1000 driver (from Realtek site) as that did not work in
the previous kernel (2.6.19-1.2895) but eth0 with the r1000 driver does work in
the last 2.6.18 kernel.

In any case there does seem to be some progress, thanks to all!  I've also
attached two files generated by the sound configuration tool.  If there is
anything further that I might provide let me know and I'll try to accomodate.

Comment 12 Walter Neumann 2007-02-16 13:58:14 UTC
Same results for me as in comment 11. But these comments should not be posted
here -- this bug is marked closed, duplicate of bug 224283.

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