Bug 313411 - init segfault on first boot in a fakeraid (dmraid) setup
init segfault on first boot in a fakeraid (dmraid) setup
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dmraid (Show other bugs)
8
All Linux
low Severity urgent
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-30 20:49 EDT by Tiago Freitas
Modified: 2009-01-09 02:17 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:17:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Without dm create in init (2.57 MB, application/octet-stream)
2008-06-18 16:08 EDT, n0n0
no flags Details
With dm create in init (2.61 MB, application/octet-stream)
2008-06-18 16:11 EDT, n0n0
no flags Details

  None (edit)
Description Tiago Freitas 2007-09-30 20:49:38 EDT
Description of problem:
Fedora 8 (KDE test2) livecd detects all raid volumes and installs fine, but on 
boot I get:

"init[1]: sefault at 00000010 eip 00159efa esp bf9072bc error 4"

/boot is on a disk outside of the raid array and / is on a fakeraid (dmraid) 
raid0 volume (second partition after windows).


Steps to Reproduce:
1. Boot fedora8.KDE.test2 livecd
2. Install / on raid0 volume (second partition) and /boot on a non-member 
(outside raid) disk
3. Boot
  
Actual results:
Boot fails with init segfault
Comment 1 n0n0 2007-12-05 16:06:01 EST
I have the same problem at boot.

"init[1]: segfault at 0000000000000010 rip 00002aaaab0f8e84 rsp 00007fff80de44b8
error 4"

Fedora 8 (x86-64) system is not on a raid disk (ATA Disk). Raid1 volume is a
ntfs volume (SATA Disks).



Comment 2 galerien 2007-12-07 13:08:40 EST
another one.
Comment 3 amdeusro 2007-12-09 07:44:34 EST
Same first-boot error here:

init[1]: segfault at 0000000000000010 rip 00002aaaab0f8e84 rsp 00007fffc0186858
error 4

Fedora 8 x86-64 installed on PATA drive. Two more SATA drives in RAID1.
Installation works only if no partition from RAID1 volume is mounted, else there
is an error after formatting / partition.
Comment 4 Andrey Tikhonov 2008-02-21 14:30:28 EST
I have exact same problem with both 64 and 32 bit installs. I have Intel Dual
Core CPU, 2 SATA drives as RAID1 (Vista), 1 IDE (target for FC8 install) and 1
SATA standalone drive (Windows XP). 

Here is the last screen for 32 bit install:
Loading dM-snapshot.ko Module
device-mapper: table: device 8:0 too small for target
device-mapper: table: 253:0: mirror: Device Lookup failure
device-mapper: ioctl: error adding target to table
device-Mapper: reload ioctl failed: No such device or address
Trying to resume froM LABEL=SWAP-sdc2
device-mapper: table ioctl failed: No such device or address
device-mapper: deps ioctl failed: No such device or address
init[1]: segfault at 00000010 eip 00159efa esp bfb194bc error 4
nash received SIGSEGV! Backtrace (14):
/bin/nash[0x805314a]
[0x12d440]
/usr/lib/libnash.so.6.0.19(nashDmDevGetNaMe+0x5a)[0x13c36b]
/usr/lib/libnash.so.6.0.19[0x1389e3]
/usr/lib/libnash.so.6.0.19[0x138b11]
/usr/lib/libnash.so.6.0.19(nashBdevIterNext+0x10b)[0x138f9f]
/usr/lib/libnash.so.6.0.19[8x139251]
/usr/lib/libnash.so.6.0.19(nashFindFsByLabel+0x2e)[0xl392a4]
/usr/lib/libnash.so.6.0.19(nashAGetPathBySpec+0x69)[0xl3942a]
/bin/nash[0x804f135l
/bin/nash[0x8052fb2l
/bin/nash[0x80536c3]
/lib/libc.so.6(__libc_start_main+0xe0)[0x461390]
/bin/nash[0x804ae61]
Comment 5 Daniel Malmgren 2008-02-22 02:01:25 EST
This is strange. This bug is classed as an initng bug, yet I see nothing in any
of the comments above about any of you actually using initng. Am I wrong here or
should it be moved to the sysvinit component instead?
Comment 6 Daniel Malmgren 2008-03-23 11:44:32 EDT
Since I didn't get any replies to comment #5 I'll assume that I'm right and that
this hasn't got anything with initng to do. Since my best guess is it has with
device-mapper to do I'll put it there...
Comment 7 Ian Kent 2008-03-23 23:48:00 EDT
Is a RAID controller present?
What is it?
Comment 8 Andrey Tikhonov 2008-03-24 02:19:13 EDT
RAID is present - Silicon Image Sil 3114 SATARaid Controller
Comment 9 Marian Minar 2008-04-08 07:49:40 EDT
I have similar problem. 
I added virtualization software Xen on Fedora 8 (x86-64).  I built HW RAID 1 on
two SATA disks where I installed Fedora 8 Linux on separate partition and swap.
Then I created another separate partition on that mirrored RAID with LVM2. Every
partition was mapped by device-mapper. 
There I put volume group and logical volume. This volume group was prepared for
Xen virtual guest disk partition. Everything was correct to this point.
I started Xen guest by ‘xm create’ without problem. I tried to connect by
vncviewer to guest vnc console and I saw looping same error message:

Init[1]: segfault at ………….. rip ………….. rsp ………… error 4 

I tried boot from CD image and I hope to see install menu for virtual guest, but
I saw only looping error message as I mentioned above.
Comment 10 n0n0 2008-04-09 06:32:54 EDT
RAID is present - Intel ICH8R (Intel Matrix Storage Technology)
Thanks
Comment 11 Marian Minar 2008-04-09 08:55:51 EDT
Thans, but my motherboard ASRock 4Core1333-Viiv has Southbridge: Intel® ICH8DH.
Northbridge: Intel® P965
Comment 12 Ian Kent 2008-04-15 12:45:56 EDT
Sorry to take so long to get back on this.
I suspect this is a problem I've worked on recently.
In any case I'll take it on and find out.

Ian
Comment 13 Ian Kent 2008-04-15 12:55:58 EDT
Any chance of someone obtaining a dump of their metadata please.
Comment 14 Marian Minar 2008-04-16 11:17:02 EDT
I will try dump some data.
Comment 15 Ian Kent 2008-04-16 12:24:32 EDT
(In reply to comment #14)
> I will try dump some data.

Can you also try doing a "dmraid -ay <anyoldstringthatsnotaraidset>"
and let me know what happens please.
Comment 16 n0n0 2008-04-26 03:11:48 EDT
Work fine with F9 and RedHat nash 6.0.47
Comment 17 Ian Kent 2008-04-27 02:01:26 EDT
(In reply to comment #16)
> Work fine with F9 and RedHat nash 6.0.47
> 

What controller?
Comment 18 n0n0 2008-04-28 07:35:35 EDT
Intel ICH8R (Intel Matrix Storage Technology)(In reply to comment #17)
> (In reply to comment #16)
> > Work fine with F9 and RedHat nash 6.0.47
> > 
> 
> What controller?

Intel ICH8R (Intel Matrix Storage Technology)
Comment 19 Ian Kent 2008-04-28 08:32:31 EDT
(In reply to comment #18)
> Intel ICH8R (Intel Matrix Storage Technology)(In reply to comment #17)
> > (In reply to comment #16)
> > > Work fine with F9 and RedHat nash 6.0.47
> > > 
> > 
> > What controller?
> 
> Intel ICH8R (Intel Matrix Storage Technology)

OK, but you're seeing this on first-boot?
Ian

Comment 20 n0n0 2008-04-29 12:57:30 EDT
(In reply to comment #19)
> (In reply to comment #18)
> > Intel ICH8R (Intel Matrix Storage Technology)(In reply to comment #17)
> > > (In reply to comment #16)
> > > > Work fine with F9 and RedHat nash 6.0.47
> > > > 
> > > 
> > > What controller?
> > 
> > Intel ICH8R (Intel Matrix Storage Technology)
> 
> OK, but you're seeing this on first-boot?
> Ian
> 
> 
No, i see that in specifications of my motherboard (Asus P5B-E Plus)
;)

Comment 21 Ian Kent 2008-04-30 02:45:41 EDT
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > Intel ICH8R (Intel Matrix Storage Technology)(In reply to comment #17)
> > > > (In reply to comment #16)
> > > > > Work fine with F9 and RedHat nash 6.0.47
> > > > > 
> > > > 
> > > > What controller?
> > > 
> > > Intel ICH8R (Intel Matrix Storage Technology)
> > 
> > OK, but you're seeing this on first-boot?
> > Ian
> > 
> > 
> No, i see that in specifications of my motherboard (Asus P5B-E Plus)
> ;)
> 
> 

Ha, I think you misunderstood.
What I'm asking is if you see the SEGV problem at first boot
with this controller, but not at other times?

What I'm trying to understand is whether this is a problem
that we know about or a different one or if it is related to
specific configurations.

Ian
Comment 22 Khamit Ardashev 2008-05-15 22:04:06 EDT
it is problem with dmraid not being properly started during first boot after
install. During install I see RAID fine. During 1st boot system cant find RAID.

errors are something about devmapper "coudln't parse string destination"

result is kernel hangs.


setup is intel dp35dp with ich9r raid and 3 disks on it as striped raid.

it works fine on FC7.
does not want to start up on FC9.

there are several bug reports similar to this, all pointing to dmraid.


if it helps:
on latest kernels in FC7 initrd file which is spplied with kernels was not
loading dmraid module and RAID was not visible after reboot. But system did
proceed w/o it since it is not root device. And I could do dmraid -ay and mount it.
So, I found on web that I could rebuild inird file with mkinird after I load
dmraid and it works again as usual, automatically mounting raid on reboot.

FC9 cant even start up, I am guessing inird is screwed up. But I don'tknow
enough how to fix it. 
Comment 23 n0n0 2008-05-30 14:46:10 EDT
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > Intel ICH8R (Intel Matrix Storage Technology)(In reply to comment #17)
> > > > > (In reply to comment #16)
> > > > > > Work fine with F9 and RedHat nash 6.0.47
> > > > > > 
> > > > > 
> > > > > What controller?
> > > > 
> > > > Intel ICH8R (Intel Matrix Storage Technology)
> > > 
> > > OK, but you're seeing this on first-boot?
> > > Ian
> > > 
> > > 
> > No, i see that in specifications of my motherboard (Asus P5B-E Plus)
> > ;)
> > 
> > 
> 
> Ha, I think you misunderstood.
> What I'm asking is if you see the SEGV problem at first boot
> with this controller, but not at other times?
> 
> What I'm trying to understand is whether this is a problem
> that we know about or a different one or if it is related to
> specific configurations.
> 
> Ian
> 

Hi,

No, all times. With F9 final, don't work too :(
With F8.92 work fine
Comment 24 n0n0 2008-06-18 16:08:07 EDT
Created attachment 309784 [details]
Without dm create in init
Comment 25 n0n0 2008-06-18 16:11:30 EDT
Created attachment 309785 [details]
With dm create in init
Comment 26 n0n0 2008-06-18 16:19:41 EDT
Comment on attachment 309784 [details]
Without dm create in init

Without dm create in init
Comment 27 n0n0 2008-07-01 19:18:30 EDT
HELP !!!!
Comment 28 Eric Sammons 2008-08-21 15:24:04 EDT
I see problem with Fedora 9, exact same problem.

device-mapper: table: 253:0: mirror: Device lookup failure
device-mapper: reload ioctl failed: No such device or address
...
/bin/nash[0x804b141]
Comment 29 Adam 2008-10-15 01:08:21 EDT
I am experiencing the exact same issue.  Using Fedora 9 final, tried 32bit & 64bit build.

OS is unusable, as it hangs upon startup.   My os is loaded on a single ide drive, I have a two drive fake-raid for my data.

argh.....
Comment 30 Khamit Ardashev 2008-10-15 15:57:27 EDT
I have found a workaround to get FC9 system on intel dp35dp going for now:

1. disconnect all fake RAID drives, leave only system disk.

2. Install FC9, do all updates.

3. hook up fake raid drives

4. dmraid -ay  ( finds and activates fake raid, you shoul dbe able to find it in /dev/mapper/ now)

example:
control  isw_ejcbcedid_Volume0  isw_ejcbcedid_Volume01


 isw_ejcbcedid_Volume01  - is the partition, which I would like to mount

5. add the device to /etc/fstab

example:
/dev/mapper/isw_ejcbcedid_Volume01            /data3                  ext3    defaults        0 0

6.  add to /etc/rc.local: 

dmraid -ay
mount /data3

of course you will see different name for mapped device, and be sure to mount partition(s), not the whole device :-).

although the system does complain on boot that it cannot mount the raid it eventually goes into rc.local and mounts it "manualy"

it seems that dmraid just have to be run somewehre earlier than rc.local, but I am not sure where ??

Anyway, it works so far with latest kernel updates:
kernel-2.6.26.5-45.fc9.x86_64
Comment 31 Adam 2008-10-16 02:31:04 EDT
Thanks bud.   That worked for me.   Thought I had tried that, but I actually had to disconnect the drives (disabling bios raid wasn't enough...)

ps.   To get rid of the error on boot, add the noauto option to your fstab entry:

/dev/mapper/isw_ejcbcedid_Volume01            /data3                  ext3   
defaults,noauto        0 0
Comment 32 Khamit Ardashev 2008-11-25 17:28:50 EST
Argh, workaround in Comment #30  does not work around any more with latest kernels   2.6.26.6-79 and up

Oh, well, no more kernel upgrades for me ...

This bug has been here for ages, hasn't somebody solved it already ?

If anybody knows a solution punch it in please.
Comment 33 Adam 2008-11-26 01:30:36 EST
I still have this bug..  it's been an issue for a while (no issue on Ubuntu or CentOS)

What I have been doing to get around this bug (since every time I do a Kernel upgrade it re-appears).

I boot with the old Kernel, rebuild the new Kernel using mkinitrd --omit-dmraid.   then boot the new Kernel.

Kinda a pain, but it works.
Comment 34 Bug Zapper 2008-11-26 02:53:26 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 to the applicable version.  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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 35 Khamit Ardashev 2008-12-18 12:17:25 EST
Workaround with mkinitrd --omit-dmraid really works for updating to new kernels.
(See Comment #33)
I think it could be called rebuilding inird image rather than rebuilding kernel.

so, together with Comment #30 and Comment #30 we have a working system now (FC9).

Thanks for helping out with workarounds.
Comment 36 Bug Zapper 2009-01-09 02:17:37 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.