Ok, it works now!! i just had to read more carefully :) Thanks all!
But I 've another question, what happens if I upgrade to new kernel version?
Because I think this dmraid 45 patch is only available kor kernel 2.6.24.16?
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
i´ve got th same problem with my Abit ip35 pro, ICH9R
I want to make a Raid 5 array, and after hours i managed, with the mdraid45
module (that appears only to be working in kernel 2.6.24.16) to build the
array and format in ntfs.
So basically i want it to be accessible in linux and windows, but
Thanks Phillip! That worked for me as well!
I can now sudo mount /dev/dm-1 /media/RAID and read and write to it
without breaking the array.
The issue where the RAID is shown as broken after a soft reboot is
resolved as well.
Some of the research that I did on this issue since my last post
And the winner is : Philip Susi :)
Thanks, it works for me !
I have other problems with installer : Installer displays bizarre patition
table, but nothing alarming. It can't format the ext3 partition. I did it
manually, without a problem, and asked installer not ot format ... But now, it
Ok, because libata is loaded as a module rather than built into the
kernel, you have to add the line:
options libata ignore_hpa=0
to /etc/modprobe.d/libata-options. After adding the line, you will need
to run sudo update-initramfs -u.
If you are booting from the livecd, then you need to add
hello, me again whit the bad english :-)
jbfoley i tried to add this to the boot line in /boot/grub/menu.lst
but after cold reboot its gone, /boot/grub/menu.lst was rewritten by ?
ok looking in the dmesg
it appears there
[0.00] Command line:
The kernel parameter does not appear to have had the intended effect. I
added this entry to menu.lst in /boot/grub and cold-booted to it:
title Ubuntu 8.04, kernel 2.6.24-16-generic (RAID fix)
root(hd0,4)
kernel /boot/vmlinuz-2.6.24-16-generic
Have you tried updating your bios yet? I also notice that the version
recorded in the signature is rather old.
According to Intel, the metadata is supposed to reside in the last two
sectors of the disk. Based on the incorrect position and the incorrect
disk size I noted that was recorded
I'll have to inform Gigabyte of the problem, then. The BIOS I have is
F4, which is the release version, but also the most recent version
available for this board. With such a new product, I guess that's the
danger. In the meantime, I'd like to see this work at least once, just
so we can confirm
Thanks, I didn't see your last message before I posted, there. I'll
give that kernel parameter a try this evening.
I still think Gigabyte needs to act on this, especially if they've got
an old version of the RAID BIOS. I think I will send them to this
thread directly.
--
ich9R raid array not
I have done some more reading of that thread on the ataraid list you
linked before, and the bug reports they reference, and it seems my
initial suspicions were correct. Your bios is using the Host Protected
Area feature to reduce the size of the disk, and the kernel is resetting
that. Could you
Currently running on kubuntu live CD 8.04.
Mobo : P35C-DS3R (rev2.0) with latest BIOS (F11e)
( First version of bios are AWFULL , nothing worked correctly... )
I added ata_ignore_hpa=0 at boot ... But it did not help :(
still have :
[EMAIL PROTECTED]:~# dmraid -ay
ERROR: isw device for volume
I read here :
http://ubuntuforums.org/showthread.php?p=4859992
that loading libata module this way :
modprobe libata ignore_hpa=0
..may help.
But how to add this option while booting on liveCD ?
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
You received this bug
No other solution than extracting the Filesystem.squashfs - modifying -
recreate an ISO ?
( long way to go for just a try ... )
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
You received this bug notification because you are a member of Ubuntu
Bugs, which is
That's what I was just trying to figure out Sebounet... but in your
case, your actual array is also broken since both disks were given
different signatures when created. You might try recreating the array
and see if they get the same signature this time. To work properly they
need the same
jbfoley, its a bug in ubuntu dmraid modules or somting else buts its in
ubuntu!
how Sebounet says if you are booting COLD in to a gentoo live cd it works fine,
fdisk shows after spliting the disk the created devices unter /dev/maper ...
but ubuntu-dmraid counts the devices up an reads the
I tried breaking the array, reformatting both drives with mkfs (ext2)
and then rebuilding the array. This time dmraid would only see one
drive of the mirror, and not the other one. I'm including my info dump
in a text file.
Perhaps this version of the Intel driver only needs to mark one drive?
I have a gentoo live CD lying around somewhere, so I'll give that a try
tonight.
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Hrm it sounds like the bios may be writing the signature to a
different location on the disk each time, and dmraid becomes messed up
when it finds the wrong one. jfboley, would you wipe the disk clean,
recreate the raid array, and then dump the last 2 megs of each disk and
post them here?
I will try this procedure this evening and post the results.
Do you want me to run this procedure on sda as well? In my current
configuration, sda is not a RAID member, and it serves as my boot disk.
sdb and sdc are the members of the RAID.
One correction, dmraid does not work correctly after a
Phillip,
I have attached the results of your suggested procedure. I took the
chance to look at them, and found that while the sig data does exist on
both drives, it is also located in very different spots on each. This
seems very strange to me, but also suggests an easy workaround and fix.
For
I moved the signature data on sdb to the same offset as that on sdc (and
zeroed out its old position.) (I moved the data from sdb to sdb, even
though it looked like the sigs on the two drives were identical.) This
resulted in the BIOS seeing the RAID as degraded, with one member disk,
and one
Masa, what you are seeing seems to agree with my most recent test.
I once again deleted the array in BIOS and re-created it, only this
time, I named it NewRAID1
When I ran dmraid -n it showed the first disk as being a part of
NewRAID1 and the second as being a part of RAID1, which was the name
When posting to a bug someone else filed to say me too you really need
to try to provide the same detailed information that others have in the
bug report to be useful. In this case, that would mean the output of
dmraid -n and dmraid -ay - -.
--
ich9R raid array not detected
Same problem here with a P35C-DS3R (rev2.0).
dmraid works fine with gentoo liveCD , with exactly same version of dmraid and
mapper.
So in my mind, the raid array is badly initialized by something else...
Maybe it comes from another module (not loaded in gentoo case) ?
--
ich9R raid array not
same here!
MOBO: Gigabyte GA-EP35-DS4 (Bios F2) (
http://www.gigabyte.de/Support/Motherboard/Driver_Model.aspx?ProductID=2678 )
CHIPSET: ICH9R Chipset
RAID: RAID0 (SATA) + RAID1(SATA)
-
I have 2 raid arrays, RAID1 and RAID0. Seems that RAID1 works and after reboot
it
[EMAIL PROTECTED]:~$ sudo dmraid -ay -vvv -d
WARN: locking /var/lock/dmraid/.lock
NOTICE: skipping removable device /dev/sdf
NOTICE: skipping removable device /dev/sdg
NOTICE: skipping removable device /dev/sdh
NOTICE: skipping removable device /dev/sdi
NOTICE: skipping removable device /dev/sdj
You re not alone, I have the same problem.
The raid was correctly detected with dmraid R13 but not usable (there was no
device for the partition). The R14 fixed this problem but now, only 1 disk is
detected by the raid and dmraid seems broken the raid.
--
ich9R raid array not detected
I tried that the first time I saw this happen, because the offline
member message when I rebooted made me think the raid had been broken
by dmraid. On a later attempt, (when I actually had some data on that
array to test) I tried a cold boot, and both Windows and the bios
recognized the array as
It looks like Intel has some bugs. Looking closely at the data, both
disks disagree on the size of the primary disk. It looks like the bios
may have a bug when creating the array which causes it to record the
size incorrectly in one of the disks, which results in the family
signature being
I have the same problem, won't recognize he RAID 1 array on my ICH9R,
(Intel X48, Gigabyte X48T-DQ6) warm reboot gives member offline for
both member disks, but a cold reboot restores them to normal operational
status. Using 8.04 Live CD. This RAID works fine under Windows.
A similar problem
The two disks appear to not be part of the same raid set. Try deleting
and recreating the raid set in the bios utility.
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Changed in: dmraid (Ubuntu)
Assignee: (unassigned) = Phillip Susi (psusi)
Status: New = In Progress
--
ich9R raid array not detected
https://bugs.launchpad.net/bugs/219393
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
In fact, it seems to be coming from somethingis else. If I simply boot
from the live cd and reboot, my raid 0 disk is marked as failed and the
raid 1 as degraded. After a cold reboot, the raid 0 is OK and the raid 1
marked as degraded.
--
ich9R raid array not detected
34 matches
Mail list logo
