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 <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)