Vor einiger Zeit hat der smartd-Dienst auf meiner Debian-GNU/Linux-Workstation eine Änderung gemeldet, der Reallocated_Sector_Count wurde um einen Wert inkrementiert (auf 1). Das bedeutet, dass ein Sektor nicht mehr gelesen werden konnte und ein Ersatzsektor aus dem Ersatzsektorvorrat der Festplatte die LBA-Adresse des defekten Sektors zugewiesen bekommen hat. Dieser Fehler deutet häufig auf einen mittelfristigen Ausfall der Festplatte hin, wobei ich bei Ausfall Datenverlust meine.
Also beschloss ich eine weitere Festplatte zu kaufen und diese dann, zusammen mit der älteren, in einem Software-Raid1-Verbund laufen zu lassen. Gesagt getan, eine weitere Seagate gekauft, Modell 7200.12. Wichtig zu erwähnen wäre hier, dass auf der Festplatte mein / zu finden ist, eine weitere /boot-Partition ist nicht vorhanden.
Nun hat Grub2 ein super Feature von seinen Entwicklern geschenkt bekommen: natives booten von einer GNU/Linux MD-Raid - Partition! Super Sache, bei einem Festplattenausfall bootet das System dennoch ohne Probleme und man wird dann lediglich per Mail informiert das eine Platte im Raidverbund Fehler wirft/ausgefallen ist. Nach dem Erhalt der Platte habe ich mich schnellstmöglich an die Konfiguration begeben, jedoch musste ich nach einiger Zeit feststellen, dass es gar nicht so einfach ist … Grub hat mir schon manchmal ein Strich durch die Rechnung gemacht, aber meistens konnte ich es noch halbwegs wieder hinbiegen.
Hier mal ein kleiner Abriss der Arbeiten, die erledigt werden mussten, um das Raid1 lauffähig und viel wichtiger bootfähig zu bekommen (ich habe mich da teilweise an die Anweisungen aus dieser Anleitung gehalten, besonders was die Grub2 Konfiguration angeht.):
1. Neue Platte nach neuen Bedürfnissen Partitioniert (lvm ist meines erachtens nicht zwingend notwendig bei einer so kleinen Installation)
2. Neue Raid-Arrays erstellt, mit einer Platte als missing(derzeitige Systemplatte) erstellt und anschließend mit ext4 formatiert. mdadm —create /dev/md0 —level=1 —raid-disks=2 missing /dev/sdb1
3. Einbinden der neuen Partition und Kopieren der Daten auf der Systempartition auf das neue Raid-Array:
mount /dev/md0 /mnt/newroot/
cp -dpRx / /mnt/newroot/
mount --bind /proc /mnt/newroot/proc
mount --bind /dev /mnt/newroot/dev
mount --bind /sys /mnt/newroot/sys
chroot newroot
4.Innerhalb der Chroot-Umgebung muss man zuerst die Datei device.map neu erstellen, damit Grub alle neuen Fesplatten/Array erkennt.
grub-mkdevicemap --no-floppy
Vorsicht! MD-Raid-Arrays werden müssen per Hand nachgetragen werden z.B. diese Zeile: /boot/grub/device.map:
(md0) /dev/disk/by-id/md-uuid-11bb8dd5:95973df2:95ef38ca:33f5f579
Welche UUID das Array besitzt erfährt man hierdurch:
mdadm --detail /dev/md0
5. Die Grub Konfiguration habe ich aus oben genannten How-To übernommen etc/grub.d/09_swraid1_setup:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry 'Debian from RAID1' --class gnu-linux --class gnu --class os {
recordfail
insmod raid
insmod mdraid
insmod ext2
set root='(md0)'
linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/md0 ro nouveau.modeset=0
initrd /boot/initrd.img-2.6.32-5-amd64
}
update-grub2
grub-install /dev/sdb --no-floppy
6. Nun ist das System meines Erachtens für einen Neustart von der neuen Platte bereit:
- - - FAIL - - -
Error: fd0 read Error
…. mehr sagt Grub2 nicht mehr … fd0? Ist doch überhaupt nicht in der device.map?
Nachfolgende Bugs beschreiben das Problem, das blöde ist nur, dass diese nicht gefixt werden und die angegebenen Workarounds nicht funktionieren. Alles probiert, vom Deaktivieren des Controllers, des Floppy-Laufwerks, des USB-Controllers - nichts hat geholfen. Das Problem betrifft nur die raid und lvm Module von Grub2 und das auch nicht auf allen Rechnern, allerdings sind es doch gerade die Module die Grub2 so interessant machen, insbesondere für den professionellen Einsatz!
Bug-Historie http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550083 https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/568720 https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/396564
Derzeitig verwendete GRUB2-Version: 1.98+20100804-13 (Debian Squeeze - unstable)