On Mon, 13 Nov 2006, martin f krafft wrote: > also sprach dean gaudet <[EMAIL PROTECTED]> [2006.11.13.1116 +0100]: > > right, now i know that i should create an /etc/default/mdadm > > *before* i install mdadm... because unlike other packages, mdadm > > does potentially dangerous things just by installing it. i'll > > keep that in mind :) > > You could also just reconfigure your debconf to show questions of > low priority; since you're juggling disks, it seems like that's the > more appropriate level. > > I have raised the question for INITRDSTART to high priority.
thanks! > > i think the only solution is to go entirely event based... start > > meshing into udev or something. you'd have to be able to express > > the dependencies of a device/filesystem somehow though. ugh. > > we have plans into this direction. yeah... i've been meaning to ramp up on them. > > actually, after playing with the disks with md, and then moving > > them into 3ware hardware raid, i did zero the disks... through the > > 3ware hw raid. the problem is that the 3ware hw raid superblock > > is even larger than the md raid superblock (100MB vs. a few MB in > > my limited experiments)... so even though i zeroed the hw raid > > device it went nowhere near the stale md superblock (even the > > 3ware hw raid superblock never touched it). > > they are likely at opposite ends of the disk. the 3ware superblock is at the end of the disk similar to mdadm... i actually successfully pulled the disks from a 3ware raid10 and constructed a md raid0 with two of the disks with mdadm --build (and recovered the data which the 3ware had decided to lose)... and i didn't have to do anything complex other than figure out which two disks to use. i've done a similar experiment with a 3ware raid1 disk... i could mount it just found on a non-3ware device. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]