Bug 427550 - dmraid segfaults on boot resulting in broken mirror
dmraid segfaults on boot resulting in broken mirror
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dmraid (Show other bugs)
5.1
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Ian Kent
Corey Marthaler
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-04 11:53 EST by Michael Young
Modified: 2010-10-22 17:33 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2008-0475
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 13:21:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to prevent SEGV when activting raid set (1.97 KB, patch)
2008-02-05 21:06 EST, Ian Kent
no flags Details | Diff

  None (edit)
Description Michael Young 2008-01-04 11:53:56 EST
I have a Centos 5 box with RAID bus controller: Intel Corporation
631xESB/632xESB SATA RAID Controller (rev 09), which installs okay, but on first
boot I get the segfault
dmraid[784]: segfault at 00000000007038a0 rip 00000000007038a0 rsp
00007fff38f14958 error 15
in dmesg after which it boots but with / mounted from /dev/sda1 rather than the
device-mapped drive, meaning that the drives aren't actually mirrored.

The offending command in the initrd appears to be
dmraid -ay -i -p "ddf1_4c53492020202020808626820000000034afad3200000a28"
and running this by hand within gdb gives
(gdb) where
#0  0x00002aaaab8aca00 in main_arena () from /lib64/libc.so.6
#1  0x00002aaaaacd000f in group_set (lc=0x42bc5a0,
    name=0x7fff50a88bb6 "ddf1_4c53492020202020808626820000000034afad3200000a28")
at metadata/metadata.c:657
#2  0x0000000000402525 in build_sets (lc=0x42bc5a0, sets=<value optimized out>)
    at toollib.c:69
#3  0x0000000000401b6a in perform (lc=0x42bc5a0, argv=<value optimized out>)
    at commands.c:664
#4  0x000000000040166e in main (argc=<value optimized out>,
    argv=0x7fff50a87428) at dmraid.c:34
(gdb) up
#1  0x00002aaaaacd000f in group_set (lc=0x42bc5a0,
    name=0x7fff50a88bb6 "ddf1_4c53492020202020808626820000000034afad3200000a28")
at metadata/metadata.c:657
657             return rd->fmt->group(lc, rd);
Comment 1 Michael Young 2008-01-04 11:54:45 EST
I forgot to mention this is on an x86_64 machine.
Comment 2 Michael Young 2008-01-04 12:46:35 EST
It looks like my problem might be related to the one mentioned here
http://www.redhat.com/archives/ataraid-list/2007-November/msg00011.html
though it still a bug because the code shouldn't segfault.
Comment 8 Ian Kent 2008-01-24 06:59:14 EST
I'll see if I can track this down.
Comment 9 Ian Kent 2008-02-05 21:06:50 EST
Created attachment 294068 [details]
Patch to prevent SEGV when activting raid set

Turns out that, for this device, if the raid set
name given doesn't exist, doesn't match an exiting
raid set name or is a sub-set of a raid set then
dmraid would SEGV.
Comment 10 Ian Kent 2008-02-05 21:10:53 EST
I'm not sure that this correction will actually resolve
the issue reported here but it does resolve the SEGV
that occurs.

Could someone give the patch posted a try please.

Ian
Comment 11 Michael Young 2008-02-06 17:33:37 EST
Yes, it seems to fix the segfault. I am currently getting around the changing
name of the raid device by hacking dmraid -ay -i -P p into the initrd instead of
the existing dmraid and kpartx lines.
Comment 12 RHEL Product and Program Management 2008-02-07 23:37:27 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 13 Ian Kent 2008-02-07 23:40:33 EST
(In reply to comment #11)
> Yes, it seems to fix the segfault. I am currently getting around the changing
> name of the raid device by hacking dmraid -ay -i -P p into the initrd instead of
> the existing dmraid and kpartx lines.

Do you mean the way dmraid won't activate the RAID a specified
individual subset?

I believe we're waiting on patches for dmraid before this
support can be added.

Ian
Comment 14 Michael Young 2008-02-08 06:39:42 EST
(In reply to comment #13)
> (In reply to comment #11)
> > Yes, it seems to fix the segfault. I am currently getting around the changing
> > name of the raid device by hacking dmraid -ay -i -P p into the initrd instead of
> > the existing dmraid and kpartx lines.
> 
> Do you mean the way dmraid won't activate the RAID a specified
> individual subset?
> 
> I believe we're waiting on patches for dmraid before this
> support can be added.
Well my main reason for moving to dmraid -ay -i -P p is that in the initrd I
couldn't use a fixed name because for these disks the full name changes between
boots (for example from
ddf1_4c53492020202020808626820000000034db222e00000a28 to
ddf1_4c53492020202020808626820000000034dd936800000a28
after a reboot). I don't know whether
dmraid -ay -i -p "ddf1_4c53492020202020808626820000000034dd936800000a28"
or similar actually starts the raid because the raid is running by the time I
can test it, so that might change the result, though currently I get
dmraid -ay -i -p "ddf1_4c53492020202020808626820000000034dd936800000a28"
No RAID sets and with names: "ddf1_4c53492020202020808626820000000034dd936800000a28"
if I try.
Comment 15 Ian Kent 2008-02-08 07:04:20 EST
(In reply to comment #14)
> > 
> > Do you mean the way dmraid won't activate the RAID a specified
> > individual subset?
> > 
> > I believe we're waiting on patches for dmraid before this
> > support can be added.
> Well my main reason for moving to dmraid -ay -i -P p is that in the initrd I
> couldn't use a fixed name because for these disks the full name changes between
> boots (for example from
> ddf1_4c53492020202020808626820000000034db222e00000a28 to
> ddf1_4c53492020202020808626820000000034dd936800000a28
> after a reboot). I don't know whether
> dmraid -ay -i -p "ddf1_4c53492020202020808626820000000034dd936800000a28"
> or similar actually starts the raid because the raid is running by the time I
> can test it, so that might change the result, though currently I get
> dmraid -ay -i -p "ddf1_4c53492020202020808626820000000034dd936800000a28"
> No RAID sets and with names:
"ddf1_4c53492020202020808626820000000034dd936800000a28"
> if I try.

I believe that's correct, assuming these are RAID subsets, that
is the message you will get. In the metadata supplied the superset
name is .ddf1_disks. But using that will activate all the subsets
which may not be what you want.

It's not possible to activate individual subsets at the moment.
Sorry.

But them the superset name shouldn't change.

Ian
Comment 22 errata-xmlrpc 2008-05-21 13:21:01 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0475.html

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