Beim starten des md Raid waren 2 Platten beim Starten nicht hochgekommen.
# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
# mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm: cannot open device /dev/sdb2: Device or resource busy
mdadm: /dev/sdb2 has no superblock - assembly aborted
Sie wurden bereits benutzt. Allerdings nicht von eine Userspace Programm / Mount wie fuser „nicht anzeigt“.
# fuser -v /dev/sdb2
An dieser Stelle haben wir vermutet das es sich um ein Fake Raid handelt. Also mal einen Blick in die device mapper blockdevices werfen…
# dmsetup table
isw_ddjcbgeaib_Volume12: 0 1875395970 linear 252:0 78124095
isw_ddjcbgeaib_Volume11: 0 78124032 linear 252:0 63
isw_ddjcbgeaib_Volume1: 0 3907039744 striped 2 256 8:16 0 8:48 0
# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 2011-08-03 23:32 /dev/sdb
In der Tat /dev/sdb wird von device mapper verwendet.
Um das Fake Raid aufzulösen haben wir die brachial Methode genommen. Hier wird mit dem Devicemapper alle Einstellungen Deaktiviert. Somit sind die platten wieder freigegeben.
# dmsetup remove_all
# dmsetup table
No devices found
Anschießend konnte das md Software Raid wieder ordentlich gestartet werden
# mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm: /dev/md0 has been started with 4 drives.
Im Endeffekt hat auf die Platten ein „Facke Raid“ mittels dmraid zugegriffen. Was auch erklärt warum die „Partitionen für den Kernel verschwunden“ waren.
apt-get autoremove dmraid