Good way of resolve this problem is to compile drivers into kernel. Then
the SATA controllers are initiated too eariler than the array building.
More about SATA and arrays using mdadm, but in polish you can find at
http://bu.bee.pl/articles.php?id=1
Regards,
Robson
Clive Menzies wrote:
On (1
On (10/05/06 16:10), Ruggiero, Stephan wrote:
> Hi,
>
> I figured it out:
>
> The problem was that during the boot process the SATA controllers are
> initiated after the array building. The IDE controllers are initiated
> earlier, that's why the RAID1 with the IDE drives worked...
>
> So I did a
Hi,
I figured it out:
The problem was that during the boot process the SATA controllers are
initiated after the array building. The IDE controllers are initiated
earlier, that's why the RAID1 with the IDE drives worked...
So I did a "lsmod | grep sata" and filled in the sata module names to the
Hi Lee,
Thank you, I will try that - but the biggest problem for me now is not the
failure of fsck but that I cannot use (read/write) the array... maybe I
missed something during the creation? I tried several times but no luck...
Best regards,
Stephan
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
On Tue, May 09, 2006 at 07:25:22PM +0200, Stephan Ruggiero wrote:
> Then I created the file system:
> mkfs.ext3 -b 4096 -R stride=16 /dev/md1
> __
> fsck.ext3: Invalid argument while trying to open /dev/md1
> /dev/md1:
> The superblock could not be read or does not describe
Hello,
I've been messing around with problem for over a week now and did not
find any solution, so this is why I hope to find help in this way...
I have a fresh debian sarge installation (kernel 2.6.8-2-386) on a
RAID 1 array (this array was created during the installation process
using t
6 matches
Mail list logo
