# DMRAID works fine in LiveCD, but SegFault's at boot [SOLVED]

## Phk

I there everyone!

I installed gentoo using Lxnay RR64 LiveCD, on a DualCore Amd64, with two Sata disk with DFI Lanparty motherboard RAID-0.

Here, in the liveCd, i can do this:

 *Quote:*   

> rr64dvd ~ # ls /dev/mapper/
> 
> control
> 
> rr64dvd ~ # dmraid -ay
> ...

 

Notice the error... But everything works fine. I did the installation using this.

Then i followed the Gentoo NVidia DMRAID Wiki, and finally, when i rebooted, i got a segmentation fault...

This is the output when booting:

 *Quote:*   

> Activating device-mapper RAID(s)
> 
> ERROR: sil: only 2/4 metadata areas found on /dev/sda, electing... 
> 
> Segmentation fault
> ...

 

..

What can the problem be? BTW, i use the latest no-sources, and also tried with the latest CK sources..

Here is the DMESG output in the Ash shell after the segfault:

 *Quote:*   

> scsi6 : sata_nv
> 
> ata8: SATA link up 1.5 Gbps (SStatus 113)
> 
> ata8: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c69 86:3e01 87:4063 88:407f
> ...

 

Thanks rightaway,

Phk!

----------

## Phk

bump?  :Sad:  i'm really in deep trouble  :Sad: 

----------

## ebichu

It's probably more to do with those "Buffer I/O Errors" than dmraid per se. (Sorry, not much help!)

----------

## nixnut

Moved from Installing Gentoo to Kernel & Hardware.

----------

## Phk

OMG....

I'm now with the LiveCD. I open 2 shells, one chrooted to my new-crashy environment.

Both answer like this:

 *Quote:*   

> rr64dvd ~ # dmraid -V
> 
> dmraid version:         1.0.0.rc8 (2005.05.19) shared
> 
> dmraid library version: 1.0.0.rc8 (2005.05.19)
> ...

 

so the version should be equal in both (LiveCD and my gentoo), but not.

When i boot to the new OS and it crashes and i type "shell", i noticed this:

 *Quote:*   

> # dmraid -V
> 
> dmraid version:         1.0.0.rc9 (2006.03._) static
> 
> dmraid library version: 1.0.0.rc9 (2006.03._)
> ...

 

How is this possible? I've chrooted once again into my new environment, and checked: the version is rc8, with device-mapper 4.4.0!!!!!

So stopping for a second reminds me only of one thing: dmraid version is directly related to kernel version?

.. re-using genkernel made me look at this:

 *Quote:*   

> * Merging
> 
> *     initramfs-base-layout.cpio.gz
> 
> *     initramfs-aux.cpio.gz
> ...

 

If anyone knows how to downgrade this little module inside genkernel, answer this..

See us,

Phk

----------

## ebichu

You can set the version of dmraid that genkernel uses in the /etc/genkernel.conf file, but you will have to put the tarball into /usr/share/genkernel/pkg/ manually if it is different to the version in the genkernel ebuild.

The other thing you could try to resolve your problem (which is possibly due to having two different ataraid signatures on your disks) is to use the dodmraid="xxx" option on your kernel boot command line in grub/lilo. Maybe dodmraid="-f nvidia -ay" but you will need to experiment! You could also try and wipe the bogus "sil" signatures if you can work out where they are on the disks.

----------

## Phk

 *ebichu wrote:*   

> You can set the version of dmraid that genkernel uses in the /etc/genkernel.conf file, but you will have to put the tarball into /usr/share/genkernel/pkg/ manually if it is different to the version in the genkernel ebuild.

 

I tried to replace the tar.bz2 file in /usr/share/genkernel/pkg/, but forgot to set it in /etc/genkernel.conf.. Thanks for the tip, ill try it rightaway.

 *ebichu wrote:*   

> The other thing you could try to resolve your problem (which is possibly due to having two different ataraid signatures on your disks) is to use the dodmraid="xxx" option on your kernel boot command line in grub/lilo. Maybe dodmraid="-f nvidia -ay" but you will need to experiment!

 

I'll try this too in next reboot.

 *ebichu wrote:*   

> You could also try and wipe the bogus "sil" signatures if you can work out where they are on the disks.

 

This part i didn't understand. Where or how are those signatures on the disk? How can i catch\delete them? I thought they were possible chipsets found, not data on the disks.

I'll report a.s.a.p.

Ah.. and THANKS ebichu =)

Phk

----------

## Phk

SOLVED!

Editing genkernel.conf and setting version to prior (1.0.0-rc8) fixed it.

Thanks ebichu, =) 

/me is happy now.

----------

## ebichu

 *Phk wrote:*   

>  *ebichu wrote:*   You could also try and wipe the bogus "sil" signatures if you can work out where they are on the disks. 
> 
> This part i didn't understand. Where or how are those signatures on the disk? How can i catch\delete them? I thought they were possible chipsets found, not data on the disks.

 

There is marker data on the disks placed there by the RAID creation routines and checked by the RAID detection routines in the ATARAID BIOS. The different vendors use different markers on the disk. DMRAID is checking the markers on the disks, not the chipset. (This is good when your computer's mobo blows up - as long as you can still connect the disks to another PC running Linux, you can use dmraid to access the RAID array for data recovery purposes no matter what chipset the other PC is using.)

 *Phk wrote:*   

> SOLVED!
> 
> Editing genkernel.conf and setting version to prior (1.0.0-rc8) fixed it.

 

That's good, but I wonder what's different in rc9?

----------

## Phk

 *ebichu wrote:*   

>  *Phk wrote:*    *ebichu wrote:*   You could also try and wipe the bogus "sil" signatures if you can work out where they are on the disks. 
> 
> This part i didn't understand. Where or how are those signatures on the disk? How can i catch\delete them? I thought they were possible chipsets found, not data on the disks. 
> 
> There is marker data on the disks placed there by the RAID creation routines and checked by the RAID detection routines in the ATARAID BIOS. The different vendors use different markers on the disk. DMRAID is checking the markers on the disks, not the chipset. (This is good when your computer's mobo blows up - as long as you can still connect the disks to another PC running Linux, you can use dmraid to access the RAID array for data recovery purposes no matter what chipset the other PC is using.)
> ...

 

I dunno, maybe it should be reported... shouldn't it?

How can i?

Thanks again

----------

## ebichu

 *Phk wrote:*   

>  *ebichu wrote:*    *Phk wrote:*   SOLVED!
> 
> Editing genkernel.conf and setting version to prior (1.0.0-rc8) fixed it. 
> 
> That's good, but I wonder what's different in rc9? 
> ...

 

It might be hard to reproduce without your disks, but perhaps you could see if it's been fixed in rc10? That should just be a case of downloading it from http://people.redhat.com/~heinzm/sw/dmraid/src/, copying it into /usr/share/genkernel/pkg/, bumping the dmraid version in /etc/genkernel.conf and rerunning genkernel.

If it hasn't been fixed, you could try contacting the developer Heinz Mauelshagen directly, but I'm sure he'd rather receive questions on the mailing list <ataraid-list@redhat.com>.

----------

## Phk

Okidoki!! Thanks little bichu  :Wink:  You were much helpfull  :Very Happy: 

Phk

----------

## ebichu

 *Phk wrote:*   

>  *ebichu wrote:*   You could also try and wipe the bogus "sil" signatures if you can work out where they are on the disks. 
> 
> This part i didn't understand. Where or how are those signatures on the disk? How can i catch\delete them? I thought they were possible chipsets found, not data on the disks.

 

You can delete the bogus "sil" signatures using dmraid itself, e.g. running it from the LiveCD:

```
dmraid -r -f sil -E
```

The above finds all block devices that appear to be part of a "sil" format raid set and prompts you to erase the metadata on each one. It will probably be a good idea to answer "n" the first time you try it. Deleting the wrong metadata would be slightly disastrous, but not impossible to recover from. It dumps the old metadata to some files and the man page has instructions for how to restore the old metadata from these files.  But if running on a LiveCD you'd better save them onto something more permanent than a RAM disk!

----------

## zxy

I have the same problem. My running kernel is 2.6.15-r1 patched with reiser4.

I tried two no-sources kernels. 2.6.16-? and 2.6.17-?. 

Both of them produced the same as above during boot. Dmraid partitions were not recognised, so I couldn't boot.

I'm afraid to recompile dmraid with symlink for kernel sources linked to no-sources kernel, because then I might not be able to boot back with my current 2.6.15-r1 kernel.

Any Idea, how to solve this. I don't use genkernel.

----------

## zxy

I've set symlink for /usr/src/linuxI to no-sources kernel  recompiled device-mapper and dmraid. And then recompiled kernel. No change. Still boot error.

----------

## ebichu

 *zxy wrote:*   

> I've set symlink for /usr/src/linuxI to no-sources kernel  recompiled device-mapper and dmraid. And then recompiled kernel. No change. Still boot error.

 

Are you using genkernel to build the initrd needed for booting? The versions of device-mapper and dmraid that genkernel uses are independent from the the sys-fs/device-mapper and sys-fs/dmraid ebuilds. You can configure the versions that genkernel uses in /etc/genkernel.conf, but if those versions disagree with the versions fetched by the sys-kernel/genkernel ebuild, you will have to fetch the different versions and place them in /usr/share/genkernel/pkg/ manually, as explained in earlier posts in this thread.

----------

## zxy

As I wrote. I don't use genkernel.

----------

## ebichu

 *zxy wrote:*   

> As I wrote. I don't use genkernel.

 

But presumably you are using an initrd if your root filesystem is on the RAID array?

----------

## zxy

Yes, I use initrd

----------

## ebichu

Well you probably know more than me then. Genkernel seemed the easiest way to go when I started using 2.6 kernels on an ATARAID system. I've never tried mkinitrd or constructing initrds manually. Genkernel's not so bad though.  :Smile: 

----------

## zxy

Here is the howto with genkernel and without genkernel

http://gentoo-wiki.com/HOWTO_Install_Gentoo_with_NVRAID_using_dmraid

Genkernel is easy, but without you can have only what you want in your kernel. Genkernel is no solution for me, that's why I dont use it.

If i recompile dmraid and create new initrd with no-sources symlinked to my /usr/src/linux folder, then I don't know if I'll still be able to boot with my older kernels.

----------

## ebichu

 *zxy wrote:*   

> Genkernel is easy, but without you can have only what you want in your kernel. Genkernel is no solution for me, that's why I dont use it.

 

You can use custom kernel configurations with genkernel pretty easily. Typically, I copy the old .config into the new kernel sources, run "make oldconfig" and sometimes "make menuconfig". Then when I'm happy, I run genkernel with the --oldconfig option and the --dmraid option. It may be possible to skip some of those steps, but I don't trust genkernel that much yet!

 *Quote:*   

> If i recompile dmraid and create new initrd with no-sources symlinked to my /usr/src/linux folder, then I don't know if I'll still be able to boot with my older kernels.

 

I'm not entirely sure why dmraid needs the /usr/src/linux folder - it must be to access some private header files. I don't think dmraid would be that fussy which particular kernel sources it is compiled against unless something pretty major has changed in the userspace-kernelspace interface. Besides, the dmraid binary in the initrd is built independently from the one built by emerge sys-fs/dmraid. On booting with the dmraid-enabled initrd, it is the version in the initrd that sets up device-mapper, before the real root partition containing the dmraid built by emerge dmraid has even been mounted!  So I'd forget about re-emerging sys-fs/dmraid for now and concentrate on getting the dmraid in the initrd working.

----------

## zxy

I tried your way, ebichu.

Compiling errors ocurred with my old configuration, so I said, let's try this genkernel once again after a long, long time. I compiled full tree  for no-sources-2.6.16-no1 and no-sources-rc1-2.6.17-no2 both produced the same error.

```

* ERROR: Failed to compile the "EXTRAS="extras/scsi_id extras/volume_id extras/ata_id extras/run_directory extras/usb_id extras/floppy extras/cdrom_id extras/firmware" USE_KLIBC=true KLCC=/var/tmp/genkernel/4833.23453.13179.3792/klibc-build/bin/klcc USE_LOG=false DEBUG=false udevdir=/dev all" target...

* -- End log... --

```

Any ideas?

--- EDIT ---

Doesnot work with gentoo-sources either.

----------

## zxy

Problem was with udev and genkernel. I changed udev version in gekernel's ebuild, emerged it again and it compiled kernel ok.

But...

It now doesn't find my nvidia-raid partitions. Boots ok, but dmraid doesn't find disks. Before dmraid starts I see in the output that devfs doesn't find /dev...

What now? 

I thought that devfs is obsolete

I'll try with no automounter support in pseudo filesystems (kernel config) 

I can still boot my other kernels and they work ok.

----------

## zxy

I found out that it is dmraid problem. Version 1.0.0-rc11 will solve this problem with 2.6.16 kernels.

See this bug here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186842

----------

