Mein Rechner ist 10 Jahre alt und die Bioschips sind defekt (einer geht garnicht mehr, der andere zickt immer mal wieder herum, je nach Einstellungen/Situation, wie ich die letzten Tage feststellen musste), wird aber demnächst repariert (werde die Chips austauschen).
Ich habe vor ca. einem halben bis einem Jahr Kubuntu 20.04 per GUI-Installationsassisten installiert, inklusive Luks-Vollverschlüsselung. Mit dem System arbeite ich jeden Tag und es sollte nach Möglichkeit schnellstmöglich wieder einsatzbereit sein (kritisch ist vor allem der darauf installierte Thunderbird und die tausend filigranen Systemeinstellungen, die ich nicht nochmal neu aufsetzen möchte). Ironischerweise ist das System abeschmiert, als ich Backups davon machen wollte... (hab leider die richtige Reihenfolge nicht strikt genug eingehalten)
Ich habe das Betriebsystem vor kurzem per
sudo dd if=/dev/sda of=/dev/sdb status=progress bs=1M
auf eine größere Festplatte kopiert (von 128GB SSD auf 256GB SSD, die alte Platte habe ich leider bereits formatiert, nachdem die neue erfolgreich getestet war, weil ich die alte für einen anderen Zweck brauchte)
Habe anschließend mit mehreren GUI-Tools (weil es per LiveCD nicht auf Anhieb klappte und ich zusätzlich mangels Rechnern einen Raspberry zu Hilfe genommen habe) mit Gpartet, Gnome-Disks-Utility und oder dem KDE-Partition-Manager die verschlüsselte Hauptpartition auf die Größe der neuen SSD vergrößert. Anschließend konnte ich das Betriebssystem auf der neuen SSD mehrmals wie gewohnt fehlerfrei neu booten und ganz normal verwenden (auch die neue Partitionsgröße wirkte). Ich habe im Bios dann Einstellungen vorgenommen, damit es möglich wird, vom USB-Stick zu booten (weil ich ein vernünftiges Zweitsystem auf USB-Stick für eben solche Fälle aufsetzen wollte), was aber aufgrund des defekten Bios dazu führte, dass nach dem Speichern der neuen Bios-Einstellungen der Bootvorgang beim Bioslogo hängen blieb (Freeze inkl. Grafikfehler) und ich den Rechner hart ausschalten musste. Nach CMOS-Clearen, Biosbatterie entfernen (weil ersteres per Button nicht zuverlässig funktionierte) und anderen Spielereien das Bios wieder gangbar zu machen (Freeze nach jedem Start und ließ sich per F12/Entf etc. nicht mehr betreten), bootete die Festplatte nicht mehr. Es erscheint die übliche Bios-Fehlermeldung, wie wenn man keine Festplatten am Rechner angeschlossen hat (hab den Text grad nicht im Kopf, den kurzen Zweizeiler kennt aber jeder). Ich habe dann über einen Raspberry per
sudo dd if=/dev/sdd of=/media/anderegroßebackupfestplatte/backupimage.img status=progress bs=1M
sicherheitshalber ein Image der gesamten Platte gezogen. (allerdings mit der vermutlich defekten Bootpartition)
Habe mir jetzt ersatzsweise auf einer anderen älteren SSD Kubuntu 20.04 installiert (auch komplett LUKS verschlüsselt), um von dort aus die Platte mit dem Hauptsystem wieder gangbar zu machen. Denn die LIVE-CD scheint nur eingeschränkt zu funktionieren (Lukspartitionen lassen sich per LIVE-CD z.B. aus irgendeinem Grund generell garnicht öffnen, habe bisher mit Live-CDs aber nur sehr selten gearbeitet) Allerdings kann ich auch auf dem neu installierten Kubuntu (welches übrigens einwandfrei bootet) nicht auf die Lukspartition meines alten Hauptsystems zugreifen, mit der Antwort das Passwort sei falsch, obwohl dieses definitv richtig ist. Andere Luks-verschlüsselte Datenträger kann ich aber hierüber ohne Probleme einhängen. Die Festplatte ist aber (laut SMART) vollkommen okey und es werden beim überprüfen der Partitionen auch keinerleri Fehler gefunden und sie lassen sich, bis auf die LUKS Partition (wo das Passwort angeblich falsch ist) einhängen.
Daher sind jetzt meine Hauptfragen folgende:
Wie kann ich den Bootbereich der Festplatte reparieren? (um die Platte wieder normal weiterzuverwenden und eine extrem aufwendige Neuinstallation zu umgehen)
Wie komme ich an die LUKS-Partition heran, um wenigstens den /Home Ordner zu sichern? (dort befindet sich noch ein sehr komplex eingerichteter Thunderbird, inklusive sämtlicher eMailverkehr, der noch nicht komplett gesichert ist).
Bilder im Anhang, die weitere Fragen aufwerfen. Z.B. warum die Bootpartitionen zwischen dem Hauptbetreibssystem und meiner aktuellen Not-Version so unterschiedlich sind, aber evtl. habe ich aufgrund der Biosproblematik damals spezielle Einstellungen getroffen) Oder warum im Terminal (lsblk) unter /DEV/SDB eine Partition plötzlich SDA6 heißt und nicht SDB6 ? Obwohl SDA bereits für eine andere Festplatte vergeben ist (/dev/sdb ist in dem Fall die Festplatte die gerettet werden muss). Aber da fehlt mir vielleicht nur das Wissen, wie Linux Laufwerke und Partitionen bennent, habe ich so bisher aber noch nie gesehen. Und noch ein Screenshot zur den Kompatibilitäten des Bios.
Bin natürlich dankbar, auf alle Fehler die ich gemacht habe und hier entdeckt werden, aufmerksam gemacht zu werden. Dass diese beim nächsten mal nicht nochmal passieren. Diesen EFI-Quatsch durchblicke ich z.B. noch nicht ganz (zu selten damit zu tun) und warum die Bootbpartitionen zwischen dem neuen Testystem und meinem eigentlichen so stark abweichen, obwohl ich der Meinung bin, beide ganz normal per GUI-Installationsassistenten ohne besonderre Einstellungen (ausser zusätzlicher LUKS Verschlüssuelung) aufgesetzt zu haben.
PS: Ich habe von der Systemplatte noch ein älteres Image, dass allerdings schon ein par Monate alt ist und aber auch während des Betriebes per DD-Befehl auf eine externe Festplatte kopiert wurde (also das System kopiert, welches gerade verwendet wird, was man ja eigentlich nicht machen sollte).
