Bug 250177 - Kernel update causes kernel panic with dmraid
Kernel update causes kernel panic with dmraid
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-30 17:10 EDT by Eero Nevalainen
Modified: 2008-06-16 22:01 EDT (History)
3 users (show)

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


Attachments (Terms of Use)
my grub.conf (863 bytes, text/plain)
2007-07-30 17:10 EDT, Eero Nevalainen
no flags Details
The requested initrd file (3.06 MB, application/octet-stream)
2007-08-03 12:48 EDT, Eero Nevalainen
no flags Details
output of 'lspci -vv' (13.35 KB, text/plain)
2007-09-23 05:34 EDT, Eero Nevalainen
no flags Details
output of 'dmidecode' (18.41 KB, text/plain)
2007-09-23 05:39 EDT, Eero Nevalainen
no flags Details

  None (edit)
Description Eero Nevalainen 2007-07-30 17:10:39 EDT
Description of problem:
New kernel updates use different entry on /boot/grub/grub.conf which does not
work with dmraid (mounting nvraid, to be exact). Changing grub entries to use
old root=LABEL=(something) restores functionality.

Version-Release number of selected component (if applicable):
2.6.22.1-27
and
2.6.22.1-33

How reproducible:
update to mentioned kernels
  
Actual results:
kernel panic
earlier warning message something like "cannot mount partition root"


Expected results:
succesful boot

Additional info:
Comment 1 Eero Nevalainen 2007-07-30 17:10:39 EDT
Created attachment 160274 [details]
my grub.conf
Comment 2 Eero Nevalainen 2007-08-01 03:26:56 EDT
Updated to kernel version 2.6.22.1-41 today. Same symptoms and workaround. I
wrote down the bootup messages on a failed boot which I'm including below:


Waiting for driver initialization
Loading dm-mod.ko module
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised - dm-devel@redhat.com
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Trying to resume from /dev/dm-5
Unable to access resume device (/dev/dm-5)
Creating root device.
Mounting root filesystem.
mount: could not find filesystem '/dev/root'
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Booting has failed.
Kernel panic - not syncing: Attempted to kill init!
Comment 3 Chuck Ebbert 2007-08-01 18:45:20 EDT
Please upload the initrd (file /boot/initrd-2.6.22.1-41.fc7.img)
Comment 4 Eero Nevalainen 2007-08-03 12:48:42 EDT
Created attachment 160628 [details]
The requested initrd file
Comment 5 Chuck Ebbert 2007-08-22 16:29:07 EDT
mkinitrd may be getting the "root=" entry from /etc/fstab. Does that have the
correct information for the '/' mount point?
Comment 6 Eero Nevalainen 2007-08-23 15:58:54 EDT
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/dm-3       /       ext3    defaults        1       1
/dev/dm-1       /boot   ext3    defaults        1       2

Looks correct to me
Comment 7 Christopher Brown 2007-09-21 09:25:35 EDT
Hello Eero,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris
Comment 8 Eero Nevalainen 2007-09-21 17:02:49 EDT
Hi Chris,

The bug still persists, although I now routinely change the 'root' entry from
/dev/dm-3 to LABEL=/ along kernel updates.

Has any dmraid developer taken a look at this? There's also one message during
the bootup which I think wasn't there before:

after 'Trying to access resume device' I get
'Unable to access resume device (/dev/dm-5)'

which implies that it can't find my swap partition in the same way it's unable
to find my root partition. Though I'm not sure if the messages were formatted
exactly as I typed above.

Cheers,
Eero
Comment 9 Christopher Brown 2007-09-21 20:01:02 EDT
Eero,

This thread might be of interest to you on fedora-devel:

https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01792.html

You might want to bash heads together about this one - I'm no raid expert I'm
afraid.

Cheers
Chris
Comment 10 Sean Bruno 2007-09-22 00:12:54 EDT
From my review of this ticket I can't see what dmraid controller the submitter
is using(not that it should matter with this type of error).

Can the submitter please indicate which controller is being used?
Comment 11 Eero Nevalainen 2007-09-22 10:31:40 EDT
Here's the output of lspci:
---------------------------
00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2)
00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb AC'97
Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5)
(rev a2)
00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc R420 JJ [Radeon X800SE]
01:00.1 Display controller: ATI Technologies Inc R420 [Radeon X800] (Secondary)
---------------------------

The motherboard is an Asus K8N. The raid is a mirror raid of 2 SATA disks. If I
remember correctly the chipset controller is sil 3114. For the software side I'm
using whatever my Fedora installer auto-detected (or updated thereafter?). Does
this answer you question?
Comment 12 Clyde E. Kunkel 2007-09-22 14:00:56 EDT
This is strangely similar to 298661 which repors a problem with root on an LV
over software raid.  There is a promise raid controller being used for discrete
SATA disks, not BIOS raid.  This problem has been around for awhile, but
apparently not reproducible by the Fedora gurus, so not fixed. 
Comment 13 Sean Bruno 2007-09-22 19:28:09 EDT
Um, The submitter has updated the ticket with an lspci that doesn't appear to
show a RAID card in the system.

In addition, the submitter posted that the RAID controller is a sil 3114.  I am
very confused about how this system is configured.

Can the submitter attach 'lspci -vv' to this ticket in addition to 'dmidecode'?
Comment 14 Eero Nevalainen 2007-09-23 05:34:15 EDT
Created attachment 203391 [details]
output of 'lspci -vv'
Comment 15 Eero Nevalainen 2007-09-23 05:39:55 EDT
Created attachment 203401 [details]
output of 'dmidecode'
Comment 16 Eero Nevalainen 2007-09-23 05:50:46 EDT
The raid setup is a "fakeraid". If I've understood correctly, the motherboard
has the sil 3114 chipset for performing some raid functions. The raid still
needs some OS software component to perform the rest of the raid functions, and
the individual disks are visible to the OS.

Bug 298661 sounds somewhat familiar, as I tried to install FC 5 earlier on my
fakeraid. Spent a lot of time and couldn't get it to work. I was very happy with
the autodetection on Fedora 7.
Comment 17 Sean Bruno 2007-09-23 15:42:54 EDT
Ok, I've looked over the attachments and I am confused.

I don't see the sil adapter listed in the h/w of the system.  Is it enabled in
the bios?  Or do you have to disable it to get the system to boot?
Comment 18 Eero Nevalainen 2007-09-24 03:57:40 EDT
It is enabled in the bios. The MBR is also located on the raid and bootable. I
guess the main difference is that it doesn't hide the underlying disks from the OS.
Comment 19 Christopher Brown 2008-01-10 14:00:28 EST
Eero,

Could I trouble you for an update - are you still having problems or have they
been resolved?
Comment 20 Eero Nevalainen 2008-01-31 11:39:56 EST
The symptoms are still there. Life's not that bad since the workaround is so 
simple.

I'll do a distro upgrade from CD later this year and check if the problem still 
persists. I'll inform you the results whatever they may be.
Comment 21 Bug Zapper 2008-05-14 09:45:47 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Bug Zapper 2008-06-16 22:01:16 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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