Bug#398310: Re: Bug#398310: don't assemble all arrays on install

[dean gaudet]

On Mon, 13 Nov 2006, martin f krafft wrote:

> also sprach dean gaudet <dean at arctic.org> [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