Re: Two isw RAID1 arrays

Hi,

> have you tried with -p in order prevent dmraid from partition activation
> and used kpartx to activate them yet to see, if that makes any diffrence
> for you ?

as previously said, "kpartx -l" worked, but "kpartx -a" gave errors.
Here they are:

device-mapper: create ioctl failed: No such device or address
device-mapper: reload ioctl failed: Invalid argument

Also, I attach the strace output for the command.

Meanwhile I booted with Knoppix 5.1 and grml 1.1 to examine the situation.
Both contain drmaid rc13 and Device-Mapper 4.10.0 (or 4.11.0). Both were able
to initialize the two RAIDs correctly with partitions. I had to activate
them one after the other, a simple "dmraid -ay" didn't work (IIRC it
activated only one RAID). But it worked. So I integrated dmraid rc13 in
my normal environment. Again, it failed to initialize the partitions.
The version of Device-Mapper there is 4.14.0 (Kernel 2.6.28.9). So it
may be a problem in the kernel. Should I file a bug, perhaps even a
regression?

My environment is a quite restricted one and contains an old glibc (2.3.2
or so). Does that matter?

Thanks,
hjb
--

-- 

New isw data offset?

I have recently received a bug report about a possible new ISW offset for disk metadata. The reporter
attached a patch that he is using to use dmraid temporarily. Yes its hard coded, but it works for him atm, and
it has the location of the metadata in it.

He is using a pair of 1TB drives in RAID level 1. The offset is in exactly the same location on both drives, so I
am not 100% sure its a host protected area issue, but this hasn't been confirmed either way yet.

Attached is the patch, and the metadata dump.

Luke

_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list

Re: Problem with kernel upgrade and dmraid (LSI megaraid)

Hello Luca,

sorry for the delay, but I have been busy lately and did not find
the time to create the log you asked for.

Attached you´ll find the startup output until it reaches the
kernel panic.

I really hope you can find the cause of this issue 

kind regards

Andreas

Luca Berra schrieb:
> On Tue, Apr 07, 2009 at 09:22:30AM +0200, Andreas Oster wrote:
>> Hello all,
>>
>> I recently have run into a problem with a server of ours (HP DL320)
>> with a raid 1 setup. The system is Mandriva Cooker and currently runs
>> kernel kernel.h-2.6.27-desktop-0.rc5.2.1mnb. Now I would like to
>> update the kernel to a newer 2.6.28 version, but if I do so the
>> system does not boot because the root partition can not be found anymore.
>>
>> I read somewhere that sometimes the IDs (lsi_xxxxxxxxx) change, when
>> changing the kernel.
> 
> this sounds very weird to me, i'd almost bet it is not the real reason.
> 
> mandriva uses redhat's initrd, which i personally despise.

Re: Problem with kernel upgrade and dmraid (LSI megaraid)

On Thu, May 07, 2009 at 04:25:44PM +0200, Andreas Oster wrote:
>Hello Luca,
>
>sorry for the delay, but I have been busy lately and did not find
>the time to create the log you asked for.
>
>Attached you´ll find the startup output until it reaches the
>kernel panic.
>
>I really hope you can find the cause of this issue 
>
i'm sorry, but still no clue,
can you also post the content of initrd init script

gzip -dc /boot/initrd-2.6.28.4-server-1mnb.img | cpio -i --to-stdout init

--

-- 
Luca Berra -- bluca <at> comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: Problem with kernel upgrade and dmraid (LSI megaraid)

Hello Luca,

attached you´ll find the content of the initrd script

Thank you for you help and patience.

kind regards

Andreas

Luca Berra schrieb:
> On Thu, May 07, 2009 at 04:25:44PM +0200, Andreas Oster wrote:
>> Hello Luca,
>>
>> sorry for the delay, but I have been busy lately and did not find
>> the time to create the log you asked for.
>>
>> Attached you´ll find the startup output until it reaches the
>> kernel panic.
>>
>> I really hope you can find the cause of this issue 
>>
> i'm sorry, but still no clue,
> can you also post the content of initrd init script
> 
> gzip -dc /boot/initrd-2.6.28.4-server-1mnb.img | cpio -i --to-stdout init
> 
> 

Re: Problem with kernel upgrade and dmraid (LSI megaraid)

Hello Luca,

here in addition, is the initrd content for the working
kernel initrd-2.6.27-desktop-0.rc5.2.1mnb.img

kind regards

Andreas

Luca Berra schrieb:
> On Thu, May 07, 2009 at 04:25:44PM +0200, Andreas Oster wrote:
>> Hello Luca,
>>
>> sorry for the delay, but I have been busy lately and did not find
>> the time to create the log you asked for.
>>
>> Attached you´ll find the startup output until it reaches the
>> kernel panic.
>>
>> I really hope you can find the cause of this issue 
>>
> i'm sorry, but still no clue,
> can you also post the content of initrd init script
> 
> gzip -dc /boot/initrd-2.6.28.4-server-1mnb.img | cpio -i --to-stdout init
> 
> 

dmraid on ICH10R controllers (Ubuntu bug 372170 call for testing)

I filed
https://bugs.edge.launchpad.net/ubuntu/+source/dmraid/+bug/372170 when I
had to replace my desktop machine - the machine smoke got out of the old
one.

I'd love it some folk could test my patch. Tests from anyone are useful,
on the unlikely chance I've really messed something up.
Particularly useful though would be some tests from people *with* ICH10R
ataraid controllers.

This will likely be desktop/workstation machines bought since
november/december last year with intel chipsets.

This particular release seems to have altered where/how the raid
metadata is stored, and my patch adds a guessed-at probe routine to the
isw format in dmraid.

How to test? - there are debs in my ppa:
https://edge.launchpad.net/~lifeless/+archive/ppa built for jaunty or
apply
http://launchpadlibrarian.net/26558415/17_fix_isw_raid_detection_1TB.patch and build yourself.
Install, run 
sudo dmraid -r -d
If you have a non-ICHxR controller, your existing ataraid setup should
be found (or non if you have none).
If you have a ICHxR but not a 10R controller, or raid disks initialized
by an earlier version of the controller, or by dmraid itself, then you
should see the first probe attempt succeed.

If you have an ICH10R controller, with disks initialized by the

Fwd: dmraid on ICH10R controllers (Ubuntu bug 372170 call for testing)

Forwarded from the ubuntu-devel list.

----- Forwarded message from Robert Collins <robert.collins <at> ubuntu.com> -----

From: Robert Collins <robert.collins <at> ubuntu.com>
To: ubuntu-devel <ubuntu-devel <at> lists.ubuntu.com>
Cc: ataraid-list <at> redhat.com
Subject: dmraid on ICH10R controllers (Ubuntu bug 372170 call for testing)
Date: Mon, 11 May 2009 18:48:12 +1000

I filed
https://bugs.edge.launchpad.net/ubuntu/+source/dmraid/+bug/372170 when I
had to replace my desktop machine - the machine smoke got out of the old
one.

I'd love it some folk could test my patch. Tests from anyone are useful,
on the unlikely chance I've really messed something up.
Particularly useful though would be some tests from people *with* ICH10R
ataraid controllers.

This will likely be desktop/workstation machines bought since
november/december last year with intel chipsets.

This particular release seems to have altered where/how the raid
metadata is stored, and my patch adds a guessed-at probe routine to the
isw format in dmraid.

How to test? - there are debs in my ppa:
https://edge.launchpad.net/~lifeless/+archive/ppa built for jaunty or
apply

Re: New isw data offset?

On Tue, May 5, 2009 at 5:45 AM, Luke Yelavich
<luke.yelavich <at> canonical.com> wrote:
> I have recently received a bug report about a possible new ISW offset for disk metadata. The reporter
attached a patch that he is using to use dmraid temporarily. Yes its hard coded, but it works for him atm, and
it has the location of the metadata in it.
>
> He is using a pair of 1TB drives in RAID level 1. The offset is in exactly the same location on both drives, so I
am not 100% sure its a host protected area issue, but this hasn't been confirmed either way yet.
>
> Attached is the patch, and the metadata dump.
>

Has the user tried disabling ignore_hpa?  Because the metadata should
always be at a constant offset.

Thanks,
Dan

Is FastTrak TX2300 supported?

Hi list,

is Promise FastTrak TX2300 [1] supported by dmraid?

It seems it is from some googling and dmraid README. However,
I need to be sure before buying it (for testing purposes :) ).

[1] http://www.promise.com/product/product_detail_eng.asp?segment=undefined&product_id=136

Thanks in advance,

--

-- 
Best regards / s pozdravem

Petr Uzel, Packages maintainer
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                          e-mail: puzel <at> suse.cz
Lihovarská 1060/12                          tel: +420 284 028 964
190 00 Prague 9                             fax: +420 284 028 951
Czech Republic                              http://www.suse.cz