Wieder ein Backup aus dem Gulli-Forum:
Hallo Leute,
Folgendes Setup:
Problem: Das Dateisystem (ext3) auf /dev/sdb1 hat sich ins Jenseits befördert, irgendwann im laufenden Betrieb während eines RAID-Growings vom RAID5. Ob das nun was damit zu tun hat oder nicht (ich glaubs ja nicht) ist auch irrelevant, es kann jedenfalls nur in den letzten Tagen passiert sein. Der Boot steigt aus mit einer kurzen Meldung von Grub, dass er das Dateisystem nicht erkennt; die Konsole kennt keine mir bekannten Befehle (auch nicht help). Da Debian sich schon vor dem Neustart gemeldet hat, habe ich die komplette Partition mit dd weggesichert, aber wohl zu spät. Ein e2fsck zeigt einen Bad superblock an und JEDE MENGE Fehler, nach einer Vollkorrektur ist die Partition leer (abgesehen vom lost+found).
Ich habe mit einer Debian-Rescue-CD problemfrei auf das Rootverzeichnis wechseln können (die RAIDs wurden schnell erkannt und bereitgestellt), das bedeutet für mich mal, dass ich keine wichtigen Daten verloren habe; ich möchte aber auch das System verständlicherweise nicht neu aufsetzen müssen. Gibt es eine euch bekannte Möglichkeit, die Bootpartition neu zu schreiben (idealerweise aus der Reparaturkonsole heraus), ohne das System irgendwie zu zerlegen? Ein grub-install wäre mir zwar möglich, aber da hab ich grad (ohne gutes Zureden von Leuten, die das besser wissen als ich) etwas Schiss: Das Letzte, was ich will, sind Probleme mit den Cryptodrives.
--- Automatisch zusammengeführter Beitrag ---
Problem gelöst - und es war sehr kurzweilig. Nachdem sich das Thema zwar viele angesehen haben, aber keiner helfen konnte (wollte nehme ich jetzt nicht an), hier meine Lösung, und auch gleich die Ursache des Problems.
Tatsächlich habe ich beim Anstöpseln des RAIDs (verwöhnt von den UUIDs) nicht auf die Steckplätze geachtet, was ein Fehler war, wie an der /etc/fstab schnell erkennbar ist:
Passiert ist also folgendes:
Eine der beiden neu angesteckten RAID5-HDDs hat den Platz der sda eingenommen, und damit die ganze Struktur um einen Buchstaben verschoben. Die ursprüngliche Plattenkonfiguration war ja, dass sda und sdb zwei identische Platten waren mit sda1 (1 GiB) als /boot und sdb1 (1 GiB) als crypted SWAP eingebunden, um so den Platz optimal zu nutzen und trotzdem das Rootsystem auf ein RAID1 legen zu können. Ergo hat kurz nach dem Boot bei der Einbindung des SWAP Debian die Bootpartition mit dem SWAP überschrieben.
Jetzt liegt die Frage natürlich auf der Hand, warum ich nicht durchgehend UUIDs verwendet habe - nun, SWAP kennt meineswissens keine UUID, und selbst wenn es sie kennen würde, wäre es durch den beim Start zufällig generierten Schlüssel völlig sinnfrei, sie zu speichern - am Neustart ist es eh wieder eine ganz andere.
im Groben und Ganzen hatte ich sogar richtig Glück - der SWAP hätte auch ne ganz andere Partition erwischen können, die tatsächlich wichtige Daten beinhaltet hätte.
Sollte es jemandem ähnlich passieren, keine Bange. Linux ist echt robust, was die Problemlösung angeht - man muss sich das nur trauen und sein System kennen.
Zunächst habe ich mir ne Rettungs-CD gebrannt und im Textmode (Rescue) hochgebootet. Für diejenigen, die das nie gemacht haben: Es fängt an wie eine normale Debian-Installation, er frägt einen den ganzen Käse und irgendwann kommt er zum Punkt, wo er dir anbietet, eine Shell in einer beliebigen Partition zu starten. Komfortabel: Die RAIDs kann er automatisch zusammenfügen, und dann kann man auch das RAID als / nutzen.
Gesagt, getan, Shell im ursprünglichen / ausgeführt und /dev/sdb1 formatiert und in /boot eingebunden:
Für diejenigen, die jetzt nach sudo fragen: Man ist automatisch root.
Danach Grub installieren:
Jetzt kommt der kniffligere Teil (der für mich dank softwaretechnisch baugleichem Schwestersystem einfach war): Man braucht die Kerneldateien, oder (wahrscheinlich, konnte ich aber aufgrund unserer Netzwerkstruktur nicht hinbekommen) Internetzugang und ein bisschen apt-get. Die Dateien sind:
(Achtung: Eure Versionsnummern müssen nicht identisch sein und sind es wahrscheinlich auch nicht)
Man würde jetzt annehmen, dass ein update-initramfs folgen muss - FALSCH! Das geht nicht aus dieser Umgebung und wird Fehlermeldungen produzieren. Ist aber auch nicht nötig, wie ich festgestellt habe. Ergo: Neustart, diesmal ohne CD. Vorher aber noch die Kerneldateien auf eine andere Partition wegsichern - ihr werdet gleich merken, warum.
Nach dem Neustart kommt man im initramfs an, das meckert, weil es das Wurzeldateisystem nicht findet. Kein Problem, es bringt alles mit, was man braucht (auch wenn es das nicht immer beim Befehl <help> mit auflistet).
Man beginne mit dem Wiederherstellen der RAIDs. Es ist sinnvoll, das mit den UUIDs zu machen, die man mit blkid rausfindet:
Nach dem exit bootet er ins md0 rein (wahrscheinlich, weil das die erste logische RAID-Möglichkeit ist, da eh keine andere Partition mehr irgendwie frei ist - die Schwestermaschine hat an der Stelle kein RAID, insofern von mir nur diese Erklärung, wo ich mich gerne korrigieren lasse). JETZT ist logischerweise (zumindest in meinem Fall) /boot wieder leer, weil ja die fstab den SWAP da drübergeschrieben hat. Ich hab das so gelöst, dass ich jetzt einfach die ehemalige SWAP-Partition (die jetzt auf sdc1 liegt) formatiert, eingebunden und mit Grub und den Kerneldateien wieder bestückt habe.
Es fehlt ein
Hallo Leute,
Folgendes Setup:
Code:
Mountpoint Device RAID-Member dmcrypt
/ /dev/md0 sdb2, sdc2 (RAID 1) Nein
/boot /dev/sdb1 Nein Nein
/home /dev/md1 sdb3, sdc3 (RAID 1) Ja
/data /dev/mapper/data sda, sdd, sde, sdf, sdg (RAID 5) Ja (inkl. GPT)
SWAP /dev/sdc1 Nein Ja (randomkey)Problem: Das Dateisystem (ext3) auf /dev/sdb1 hat sich ins Jenseits befördert, irgendwann im laufenden Betrieb während eines RAID-Growings vom RAID5. Ob das nun was damit zu tun hat oder nicht (ich glaubs ja nicht) ist auch irrelevant, es kann jedenfalls nur in den letzten Tagen passiert sein. Der Boot steigt aus mit einer kurzen Meldung von Grub, dass er das Dateisystem nicht erkennt; die Konsole kennt keine mir bekannten Befehle (auch nicht help). Da Debian sich schon vor dem Neustart gemeldet hat, habe ich die komplette Partition mit dd weggesichert, aber wohl zu spät. Ein e2fsck zeigt einen Bad superblock an und JEDE MENGE Fehler, nach einer Vollkorrektur ist die Partition leer (abgesehen vom lost+found).
Ich habe mit einer Debian-Rescue-CD problemfrei auf das Rootverzeichnis wechseln können (die RAIDs wurden schnell erkannt und bereitgestellt), das bedeutet für mich mal, dass ich keine wichtigen Daten verloren habe; ich möchte aber auch das System verständlicherweise nicht neu aufsetzen müssen. Gibt es eine euch bekannte Möglichkeit, die Bootpartition neu zu schreiben (idealerweise aus der Reparaturkonsole heraus), ohne das System irgendwie zu zerlegen? Ein grub-install wäre mir zwar möglich, aber da hab ich grad (ohne gutes Zureden von Leuten, die das besser wissen als ich) etwas Schiss: Das Letzte, was ich will, sind Probleme mit den Cryptodrives.
--- Automatisch zusammengeführter Beitrag ---
Problem gelöst - und es war sehr kurzweilig. Nachdem sich das Thema zwar viele angesehen haben, aber keiner helfen konnte (wollte nehme ich jetzt nicht an), hier meine Lösung, und auch gleich die Ursache des Problems.
Tatsächlich habe ich beim Anstöpseln des RAIDs (verwöhnt von den UUIDs) nicht auf die Steckplätze geachtet, was ein Fehler war, wie an der /etc/fstab schnell erkennbar ist:
Code:
proc /proc proc defaults 0 0
# / was on /dev/md0 during installation
UUID=111 / ext3 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=112 /boot ext2 defaults 0 2
/dev/mapper/md1_crypt /home ext3 defaults 0 2
[COLOR="#FF0000"]/dev/mapper/sdb1_crypt[/COLOR] none swap sw 0 0
/dev/mapper/data /home/user/data ext4 defaults 0 2Eine der beiden neu angesteckten RAID5-HDDs hat den Platz der sda eingenommen, und damit die ganze Struktur um einen Buchstaben verschoben. Die ursprüngliche Plattenkonfiguration war ja, dass sda und sdb zwei identische Platten waren mit sda1 (1 GiB) als /boot und sdb1 (1 GiB) als crypted SWAP eingebunden, um so den Platz optimal zu nutzen und trotzdem das Rootsystem auf ein RAID1 legen zu können. Ergo hat kurz nach dem Boot bei der Einbindung des SWAP Debian die Bootpartition mit dem SWAP überschrieben.
Jetzt liegt die Frage natürlich auf der Hand, warum ich nicht durchgehend UUIDs verwendet habe - nun, SWAP kennt meineswissens keine UUID, und selbst wenn es sie kennen würde, wäre es durch den beim Start zufällig generierten Schlüssel völlig sinnfrei, sie zu speichern - am Neustart ist es eh wieder eine ganz andere.
im Groben und Ganzen hatte ich sogar richtig Glück - der SWAP hätte auch ne ganz andere Partition erwischen können, die tatsächlich wichtige Daten beinhaltet hätte.
Sollte es jemandem ähnlich passieren, keine Bange. Linux ist echt robust, was die Problemlösung angeht - man muss sich das nur trauen und sein System kennen.
Zunächst habe ich mir ne Rettungs-CD gebrannt und im Textmode (Rescue) hochgebootet. Für diejenigen, die das nie gemacht haben: Es fängt an wie eine normale Debian-Installation, er frägt einen den ganzen Käse und irgendwann kommt er zum Punkt, wo er dir anbietet, eine Shell in einer beliebigen Partition zu starten. Komfortabel: Die RAIDs kann er automatisch zusammenfügen, und dann kann man auch das RAID als / nutzen.
Gesagt, getan, Shell im ursprünglichen / ausgeführt und /dev/sdb1 formatiert und in /boot eingebunden:
Code:
mke2fs -T ext2 /dev/sdb1
mount /dev/sdb1 /bootDanach Grub installieren:
Code:
grub-install /dev/sdb
Code:
config-2.6.32-5-amd64
initrd.img-2.6.32-5-amd64
System.map-2.6.32-5-amd64
vmlinuz-2.6.32-5-amd64Man würde jetzt annehmen, dass ein update-initramfs folgen muss - FALSCH! Das geht nicht aus dieser Umgebung und wird Fehlermeldungen produzieren. Ist aber auch nicht nötig, wie ich festgestellt habe. Ergo: Neustart, diesmal ohne CD. Vorher aber noch die Kerneldateien auf eine andere Partition wegsichern - ihr werdet gleich merken, warum.
Nach dem Neustart kommt man im initramfs an, das meckert, weil es das Wurzeldateisystem nicht findet. Kein Problem, es bringt alles mit, was man braucht (auch wenn es das nicht immer beim Befehl <help> mit auflistet).
Man beginne mit dem Wiederherstellen der RAIDs. Es ist sinnvoll, das mit den UUIDs zu machen, die man mit blkid rausfindet:
Code:
blkid /dev/sdb2
mdadm -A --uuid=<UUID> md0
blkid /dev/sdb3
mdadm -A --uuid=<UUID> md1
blkid /dev/sda
mdadm -A --uuid=<UUID> md2
exitEs fehlt ein
und die Kiste läuft wieder, weil jetzt die RAIDs wieder hübsch so sind, wie er sie erwartet und assemblen soll.