Grub zerschossen - bitte um Hilfe

[am2]

Ich musste (leider) Windows 10 installieren. Danach war mein Grub weg (logisch...). Wie kann ich ihn wieder in dem MBR installieren? Die Jessie-DVD im Rettungsmodus hat nicht geholfen, bzw. ich komme damit nicht zurecht. Ich habe RAID 0, auf md0 liegt /boot, auf md1 /root (verschlüsselt) und auf md2 /home (auch verschlüsselt). Gibt es eine Möglichkeit den Grub zurück zu bekommen?

[MartinV]

Die Super Grub CD ist Dein Freund
Damit debian booten, und dort

Code: Alles auswählen

update grub
grub-install /dev/sda

ausführen.

[am2]

Klappt es auch bei verschlüsselten Systemen?

[sbruder]

Klappt es auch bei verschlüsselten Systemen?

Meines Wissens nach schon, da die SuperGrubDisk ja versucht Reste des alten Grubs zu verwenden (/boot; unverschlüselt) und Dein installiertes Debian wird wohl seinen eigenen Bootloader installieren können.

[am2]

Das war auch mein Gedankengang, leider wurde ich enttäuscht. Super Grub Disk sieht mein RAID-Debian nicht wirklich. Ich kann die RAID-Unterstützung zwar aktivieren, sehe meine md's aber ich kann nicht davon booten, da mir mein RAID-Debian nicht als Boot-Option angeboten wird. Rettungsmodus der Installations-DVD taugt auch nichts...

Der nächste Schritt war Debian-Installation auf der dritten Festplatte, da wo auch die Windows-Systeme liegen. Es klappt wunderbar, Grub wird in den MBR einwandfrei installiert aber auch hier wird mein RAID-Debian nicht gesehen. An die Daten des RAID komme ich dran und irgendwie habe ich das Gefühl, dass ich mein /home sichern und das System neu aufsetzen muss...

[sbruder]

ja das mit dem RAID-0 ist etwas schwierig, das hatte ich nicht bedacht. Ist bei RAID-0 die /boot nicht ausserhalb?

[am2]

Ich habe insgesamt drei Partitionen auf dem RAID: /boot, /root (verschlüsselt) und /home (auch verschlüsselt). Ich sage: die Verschlüsselung der /root-Partition ist an allem schuld. Ich kopiere gerade mein /home auf eine externe Festplatte und setzte alles neu auf. Partitionierung bleibt, RAID auch aber diesmal wird nur /home verschlüsselt. Unter dem Strich ging die Welt noch nicht unter, es hätte aber schlimmer ausgehen können.

[sbruder]

Moment, ist /root (das Homeverzeichnis von root) oder / (Das Root/Wurzelverzeichnis) verschlüsselt? /root zu verschlüsseln macht m.E. keinen Sinn, sinnvoller wäre / ganz zu verschlüsseln.

[am2]

Verschlüsselt ist / (also die gesamte Wurzel-Partition) und nicht nur /root (d.h. home von User root). Ich bin hier mit den Begrifflichkeiten etwas durcheinander geraten. Die Verschlüsselung von / nimmt /root natürlich auch mit.

Als ich die ganze Zeit /root schrieb meinte ich tatsächlich die Partition mit dem Einhängepunkt / (auch root-Partition genannt...)

[sbruder]

OK, das habe ich verstanden. Iche denke eher, dass es nicht an der Crypto auf / liegt sondern am RAID-0.
Gerade fällt mir ein: Für so eine Problematik habe ich schon einmal Rescatux [1] verwendet, zwar ohne RAID-0, eventuell geht das damit aber.

[1] http://www.supergrubdisk.org/rescatux/

[am2]

Update:
System ist neu aufgesetzt, DaSi zurückgespielt, alles wieder soweit OK. Dieses mal habe ich auf die Verschlüsselung von / verzichtet, nur das /home-Verzeichnis ist verschlüsselt. Eine spezielle Rettungsdisk werde ich vermutlich nicht mehr benötigen, denn die Jessie-Installations-DVD bietet einen Rettungsmodus, der u.a. auch eine GRUB-Installation bietet. Da / diesmal unverschlüsselt ist, kann ich sie ohne Probleme einbinden.

Das war es dann zum Thema Verschlüsselung und Desaster-Recovery...

[rendegast]

Ich halte raid0 für den Anwendungsfall hier (/boot, System) denkbar schlecht geeignet.

[am2]

Gut, dazu kann ich jetzt nichts sagen, zumal es damit bis jetzt noch nie Probleme gab. GRUB-Reparaturen waren reine Routine, die ein Wenig Zeit gekostet hat, mehr nicht. Ich tippe da wirklich auf die Verschlüsselung von / als Hauptursache, denn jetzt geht es so wie früher.

Aber was macht RAID 0 so schlecht für diesen Anwendungsfall?

[rendegast]

Aber was macht RAID 0 so schlecht für diesen Anwendungsfall?

raid0 soll Erhöhung der Schreibrate bringen.
Das ist bei /boot / System weniger ein Thema.
Ein passender Anwendungsfall scheint mir Videobearbeitung.

Bei /boot / System wird lediglich das Ausfahlrisiko erhöht. -> raid1

[am2]

Einverstanden. Aber ich bin bisher mit nur einer FP gut zurecht gekommen und irgendwann kam der Wunsch nach mehr Kapazität sowie Schreib-/Lesepower. Nicht nur Video-Bearbeitung, auch das Kopieren von etlichen GB spielt bei mir eine Rolle. Was lag da näher als RAID 0? Alles ist jetzt schneller als die SSD im MacBook Pro meiner Tochter Die Ausfallwahrscheinlichkeit (-Anfälligkeit) ist bei RAID 0 wie bei einer einzigen FP, es hat sich also prinzipiell nichts geändert. Und am FP-Ausfall des RAID 0 lag es bei mir nun wirklich nicht.

[rendegast]

Die Ausfallwahrscheinlichkeit (-Anfälligkeit) ist bei RAID 0 wie bei einer einzigen FP, es hat sich also prinzipiell nichts geändert.

Nein, die Ausfallwahrscheinlichkeit ist bei 2 Platten verdoppelt.

Nicht nur Video-Bearbeitung, auch das Kopieren von etlichen GB spielt bei mir eine Rolle.

Reicht es nicht aus, wenn nur diese Bereiche auf einem raid0 liegen?

[am2]

Nein, die Ausfallwahrscheinlichkeit ist bei 2 Platten verdoppelt.
(...)
Reicht es nicht aus, wenn nur diese Bereiche auf einem raid0 liegen?

Stimmt (mit der Ausfallwahrscheinlichkeit), aber es war KEIN AUSFALL. Ich habe wieder RAID 0 und es läuft rund wie vorher.

"Diese Bereiche" müsste dann mein ganzes home-Verzeichnis sein, also fast 2 TB, denn da finden doch die meisten Bewegungen statt. Oder ich installiere künftig so, dass / und /boot auf der alten Solo-FP liegen und /home dann das gesamte RAID 0 für sich beansprucht. Wäre auch einer Überlegung wert... Die Ausfallwahrscheinlichkeit wird dann nochmal höher