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).

another one.

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.

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]

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?

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...

Is a RAID controller present?
What is it?

RAID is present - Silicon Image Sil 3114 SATARaid Controller

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.

RAID is present - Intel ICH8R (Intel Matrix Storage Technology)
Thanks

Thans, but my motherboard ASRock 4Core1333-Viiv has Southbridge: Intel® ICH8DH.
Northbridge: Intel® P965

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

Any chance of someone obtaining a dump of their metadata please.

I will try dump some data.

(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.

Work fine with F9 and RedHat nash 6.0.47

(In reply to comment #16)
> Work fine with F9 and RedHat nash 6.0.47
> 

What controller?

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)

(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

(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)
;)

(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

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. 

(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

Created attachment 309784 [details]
Without dm create in init

Created attachment 309785 [details]
With dm create in init

Comment on attachment 309784 [details]
Without dm create in init

Without dm create in init

HELP !!!!

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]

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.....

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

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

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.

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.

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

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.

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.