Package: debian-installer
Version: 20081029
Severity: grave

I have a system with /dev/sd{a1,b2} and /dev/sd{a2,b3} being two
separate RAID1s, /dev/md[01] respectively.

Due to historic reasons, /dev/sdb1 is a small partition with
something else.

Also, historically, /dev/sd[ab] used to be part of an array
themselves (the whole disk, not just a partition). As a result,
mdadm could identify three arrays on this system:

1. /dev/sd[ab]
2. /dev/sd{a1,b2}
3. /dev/sd{a2,b3}

I wanted to run mdadm --zero-superblock on /dev/sd[ab] to clear up
the mess and because I have a working netboot setup, I thought I'd
just use the Debian-installer's rescue mode to get exclusive access
to the disks, which mdadm needs.

I started rescue mode and was surprised that only /dev/sd[ab] were
created, but no partitions. A glance into /proc/mdstat shows that
the installer had auto-assembled /dev/sd[ab] into /dev/md0 and md
was happily synchronising and overwriting my /dev/sdb1 partition.

Arguably, since /dev/sd[ab] held valid superblocks, they could have
been assembled. However, the other two pairs also held valid
superblocks, yet the installer didn't care.

I strongly oppose to any form of RAID auto-assembly in rescue mode,
which is only a sure-fire way to wreck your data. Auto-assemble
should not take place especially when there are nested superblocks.

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

.''`. martin f. krafft
: :' : proud Debian developer, author, administrator, and user
`. `'` -
`- Debian - when you have better things to do than fixing systems

Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkW+b4ACgkQIgvIgzMMSnV6ogCgghQp7FtTsv DONJsD1+4jt81a