Bug 137273 - kernel oops in raid5_unplug_device using disk druid under anaconda
Summary: kernel oops in raid5_unplug_device using disk druid under anaconda
Keywords:
Status: CLOSED DUPLICATE of bug 127862
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-27 06:29 UTC by Ellen Shull
Modified: 2015-01-04 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-29 18:23:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg w/oops under .640, FC3-rc1 in text install (7.47 KB, text/plain)
2004-10-27 06:31 UTC, Ellen Shull
no flags Details
dmesg w/oops under .643, FC3-rc2 in graphical install (7.47 KB, text/plain)
2004-10-27 06:31 UTC, Ellen Shull
no flags Details
full dmesg from .643 boot to fresh FC3-rc2 install (14.80 KB, text/plain)
2004-10-27 06:32 UTC, Ellen Shull
no flags Details

Description Ellen Shull 2004-10-27 06:29:55 UTC
Description of problem: 
Installing the FC3 rc (both rc1 with .640 and now rc2 with .643), 
there is a kernel oops when I go to assign a mount point to my 
existing/formatted RAID 5 array in disk druid.  Happens in both 
graphical and text install.  I'm not installing on the raid array 
itself (have an existing rawhide install there) so I'm not sure if 
this oops affects ability to access the RAID from that point on; the 
install continues on fine to sda2 in my case. 
 
Version-Release number of selected component (if applicable): 
2.6.9-1.640 
2.6.9-1.643 
 
How reproducible: 
always 
 
Steps to Reproduce: 
0.  Have an existing RAID 5 array.  Mine was originally created 
somewhere around RHL 7-9 time, not exactly sure. 
1.  Boot rescue CD, start install 
2.  select HTTP install 
3.  do manual partition using disk druid; assign mount point to RAID 
5 array. 
 
steps 1-2 probably aren't relevant, but that's the process I've been 
doing.  Actually the whole install thing may not be relevant, maybe 
raidstart and then raidstop in rescue mode from one of these .64x 
discs is enough to show it?  I should try that, duh. 
   
Actual results: 
in text mode, you actually see the oops pop up on the background; in 
graphical, you don't see it.  In either case go to the shell on 
console 2 (or wherever it is) and dmesg and you'll get the full text 
of the oops. 
 
Expected results: 
No oops! 
 
Additional info: 
Attached are three sample dmesg dumps: 
1) 'dmesg' command output (thus only recent bits) from rc1 with .640, 
in 'linux text' install, showing the oops 
2) 'dmesg' from rc2 with .643, graphical install, showing oops again 
3) /var/log/dmesg showing complete boot under .643 from fully 
installed system so you can see what hardware is all there.

Comment 1 Ellen Shull 2004-10-27 06:31:16 UTC
Created attachment 105824 [details]
dmesg w/oops under .640, FC3-rc1 in text install

Comment 2 Ellen Shull 2004-10-27 06:31:47 UTC
Created attachment 105825 [details]
dmesg w/oops under .643, FC3-rc2 in graphical install

Comment 3 Ellen Shull 2004-10-27 06:32:41 UTC
Created attachment 105826 [details]
full dmesg from .643 boot to fresh FC3-rc2 install

Comment 4 Dave Jones 2004-10-29 18:23:28 UTC

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


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