debian startet nicht mehr komplett nach Stromausfall

[raiuns]

Liebe alle,

ich habe mich schon lange nicht mehr mit debian beschäftigt, einfach weil mein mini-headless-Server über Jahre prima lief.

Nun gab es einen Stromausfall - danach hatte er die Uhrzeit vergessen (CMOS-Batterie leer), die habe ich ersetzt und die Uhr gestellt, soweit im BIOS alles ok.

Dann booetet er bis zur Auswahl (Debian oder erweiterte Optionen), dann schreibt er noch ich glaube "loading initial Ramdisk" (geht sehr schnell) und danach habe ich nur einen oben links blinkenden Cursor.

Nun wollte ich per angestecktem USB-CD-Laufwerk ein "Rescatux" booten, aber von USB bootet er gar nicht, erkennt auch das Laufwerk nicht.

Die Festplatte ist eine SSD, ich denke nicht dass da etwas "defekt" ist.

Frage: kann ich mit der angeboteten "grub" minikonsole etwas Sinnvolles ausrichten, sollte ich die Festplatte ausbauen, an einen Laptop per USB anschließen und da Sachen ändern - also kurz wie bekomme ich ihn wieder zum Laufen / den Fehler eingegrenzt?

[MSfree]

Nun wollte ich per angestecktem USB-CD-Laufwerk ein "Rescatux" booten, aber von USB bootet er gar nicht, erkennt auch das Laufwerk nicht.

Booten von USB muß bei deiner 16 Jahre alten Kiste im BIOS eingeschaltet werden, ggfls. ist auch die Bootreihenfolge einzustellen.

Dann booetet er bis zur Auswahl (Debian oder erweiterte Optionen), dann schreibt er noch ich glaube "loading initial Ramdisk" (geht sehr schnell) und danach habe ich nur einen oben links blinkenden Cursor.

Du kannst im Grub die Kommandozeile des zu bootenden Kernels editieren und das "quiet" löschen. Danach sollte es ein paar mehr Meldungen geben. Das löst zwar das Bootproblem nicht, gibt aber eventuell ein paar Hinweise.

sollte ich die Festplatte ausbauen, an einen Laptop per USB anschließen und da Sachen ändern

Du könntest zumindest mit einem zweiten Rechner die SSD mittels USB-Adapter mal mit fsck alle Partitionen prüfen und deren Dateisysteme reparieren lassen. Meistens reicht das schon, um das System wieder bootfähig zu bekommen, wenn man sonst kein Rettungssystem gebootet bekommt.

[mat6937]

... mein mini-headless-Server über Jahre prima lief.

Nun gab es einen Stromausfall - danach hatte er die Uhrzeit vergessen (CMOS-Batterie leer), die habe ich ersetzt und die Uhr gestellt, soweit im BIOS alles ok.

Wenn die CMOS-Batterie leer war bzw. ersetzt worden ist, hast Du jetzt im BIOS die Standardeinstellungen. Bist Du sicher, dass diese für deinen Server auch OK sind?

[raiuns]

Du könntest zumindest mit einem zweiten Rechner die SSD mittels USB-Adapter mal mit fsck alle Partitionen prüfen und deren Dateisysteme reparieren lassen. Meistens reicht das schon, um das System wieder bootfähig zu bekommen, wenn man sonst kein Rettungssystem gebootet bekommt.

Hab ich mal gemacht:

Code: Alles auswählen

$ sudo fsck /dev/sdb
fsck von util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext2: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
fsck.ext2: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdb zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

In /dev/sdb wurde eine dos-Partitionstabelle gefunden

wenn ich unter Ubuntu mit "Laufwerke" drauf schaue werden mit korrent 2 ext4-Partitionen angezeigt.. Wie bekomme ich den Superblock wieder hin? Ich kann auch eine Partition lesen (die beim Anstecken automatisch eingehängt wird), inkl. aller Dateien (ist u.a. ein Owncloud-server)

Und ich habe aus der /etc/default/grub das "quiet" rausgenommen - mal sehen was passiert..

[MSfree]

Code: Alles auswählen

$ sudo fsck /dev/sdb

Das kann nicht gehen.

Du kannst nur Partitionen fsck'en und nicht das Raw-Device.

Schau mit lsblk -f nach, welche Partitionen auf /dev/sdb liegen und fsck'e die ext2/3/4-Partitionen, zum Beispiel mit

Code: Alles auswählen

fsck /dev/sdb1

[raiuns]

Ah ja - lang ist's her.

also Ergebnisse:

Code: Alles auswählen

$ sudo fsck /dev/sdb1
fsck von util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdb1: sauber, 322953/3407872 Dateien, 11231331/13608448 Blöcke

Code: Alles auswählen

$ sudo fsck /dev/sdb2
fsck von util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
Die Größe des Dateisystems (laut Superblock) ist 44999062 Blöcke.
Die physikalische Größe des Gerätes ist 44999061 Blöcke.
Entweder ist der Superblock oder die Partionstabelle beschädigt!
Abbrechen<jy>? nein
/dev/sdb2 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen.
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
/lost+found nicht gefunden.  Erstellen<jy>? nein
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
Die Anzahl freier Blöcke ist falsch (23179387, gezählt=21114405).
Reparieren<jy>? ja
Die Anzahl freier Inodes ist falsch (11224950, gezählt=11155625).
Reparieren<jy>? ja

/dev/sdb2: ***** DATEISYSTEM WURDE VERÄNDERT *****

/dev/sdb2: ********** WARNUNG: Noch Fehler im Dateisystem  **********

/dev/sdb2: 100183/11255808 Dateien (0.7% nicht zusammenhängend), 23884657/44999062 Blöcke

wenn ich erneute teste, dann erscheint wieder der gleiche Fehler.. was kann ich noch tun?

[raiuns]

also was ich meinte: Beim erneiten Ausführen werden immer noch Fehler angezeigt, obwohl ja vorhin "repariert" wurde. Hab ich noch eine Chance?
Was auch doof ist: die "wichtige" erste Partition lebt ja nochund ist in Ordnung - da würde ich g3erne von booten - bruache ich eine Ersatz ssd oder msint ihr die aktuelle hat noch eine Chance und ist nur "verwirrt" statt defekt?

Code: Alles auswählen

$ sudo fsck /dev/sdb2
fsck von util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
Die Größe des Dateisystems (laut Superblock) ist 44999062 Blöcke.
Die physikalische Größe des Gerätes ist 44999061 Blöcke.
Entweder ist der Superblock oder die Partionstabelle beschädigt!
Abbrechen<jy>? nein
/dev/sdb2 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen.
Durchgang 1: Inodes, Blöcke und Größen werden geprüft

Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
/dev/sdb2: 100184/11255808 Dateien (0.7% nicht zusammenhängend), 23884658/44999062 Blöcke

[fischig]

Bezieht sich deine Signatur auf die gestörte Maschine? Da steht als Datenträger HDD, nicht SSD. Das bringt mich zu der Frage.

[raiuns]

Bezieht sich deine Signatur auf die gestörte Maschine? Da steht als Datenträger HDD, nicht SSD. Das bringt mich zu der Frage.

Nein - gut dass du fragst, auf die Signatur habe ich gar nicht geachtet.

[fischig]

Dann wäre vielleicht mal angesagt mitzuteilen, auf welcher Maschine das System läuft. Die verwendeten Begriffe „BIOS“ und „Superblock“ lese ich so, dass das kein EFI-System ist.

[raiuns]

Sowas: Intel Atom D2550 (DualCore 1,86GHz) 4GB DDRIII, 60GB SSD, USB 3.0, HDMI, Mµ-Style (fanless)

https://www.amazon.de/gp/product/B007QN ... UTF8&psc=1

[fischig]

Das Gerät ist also ausweislich des amazon-Artikels mindestens 12 Jahre alt. Das deutet darauf hin, dass efi noch nicht im Spiel sein könnte. Letzteres müssten die hiesigen Cracks beurteilen. Wenn das der Fall ist und nur dann (kein efi), versuchte ich von außen via chroot auf das System zu kommen, den ärgerlichen grub durch lilo (letztmals vorhanden in buster) zu ersetzen und damit zu booten. Das wird mir jetzt wohl böse Haue von den cracks eintragen. (lilo funktioniert hier noch mit bookworm.)

[raiuns]

Also ich stelle die Frage mal zurück, ob die zweite Partition einfach zu retten ist (ich müsste sie sonst aus vielen Inkrementen Sicherungen wieder zusammenfummeln), ich denke es hat auch nicht unbedingt was zu tun mit der Maschine, an die sie angeschlossen ist.

Da die erste Partition ja noch "lebt" dachte ich mir, ich nehme Clonezilla und kopiere die Partition damit auf eine neue leere Platte, und installiere dann irgendwie grub nach (wie)? - sollte reichen, oder / Geht es einfacher?

[MSfree]

Also ich stelle die Frage mal zurück, ob die zweite Partition einfach zu retten ist (ich müsste sie sonst aus vielen Inkrementen Sicherungen wieder zusammenfummeln)

Hast du überhaupt schon mal versucht, nach der Reperatur die Platte zu booten? Die kleine Diskrepanz

Code: Alles auswählen

Die Größe des Dateisystems (laut Superblock) ist 44999062 Blöcke.
Die physikalische Größe des Gerätes ist 44999061 Blöcke.

ensprechen 512 Bytes. Wie die zutsande gekommen ist, weiß ich natürlich auch nicht, gänzlich unproblematisch ist das auch nicht. Ich würde trotzdem versuch, die zu mounten, u.U. read-only. Dann kann man den Inhalt wenigstens mal irgendwo hin sichern.

Da die erste Partition ja noch "lebt"...

Ich kenne dein Partitionsschema nicht, du hast es bisher auch nicht mitgeteilt. Üblicherweise ist die erste Partition aber nur die /boot-Partition, die nur den Kernel und die initrd beinhaltet. Davon wird das System nicht vollständig booten können. Das Betriebssystem mit allen seinen Dienstprogrammen befindet sich überlicherweise auf der zweiten Partition, die als /-Partition gemountet wird.

...Wenn das der Fall ist und nur dann (kein efi), versuchte ich von außen via chroot auf das System zu kommen, den ärgerlichen grub durch lilo (letztmals vorhanden in buster) zu ersetzen und damit zu booten.

Laut allererstem Post erscheint schon die Meldung "loading initial Ramdisk". Zu dem Zeitlpunkt ist der Kernel bereits geladen und der versucht dann, die initrd zu laden. In der initrd befinden sich Programme, die unter anderem versuchen, das /-Dateisystem zu mounten, was vermutlich schief geht.

An der Stelle, wo diese Meldung kommt, ist grub bereits nicht mehr aktiv und hat seine Arbeit getan. Kein Grund also, auf grub zu schimpfen, denn das funktioniert offensichtlich völlig problemlos.

[fischig]

An der Stelle, wo diese Meldung kommt, ist grub bereits nicht mehr aktiv

Weiß man's? Als user? Benutzt er eine initrd? Ich tu's meistens nicht.
Ich trau' grub nach meiner Erfahrung jeden Mist zu. Der Anspruch ist ja, dem Benutzer möglichst zu verschweigen, dass er ihn überhaupt benutzt. Ich umginge den, wenn irgend möglich/nötig. Aber ok, meine Meinung muss man nicht akzeptieren.

Wenn er systemd (und efi) nutzt, hätte ich ihm KP97 empfohlen. aber er hält sich ja mit infos ziemlich bedeckt.

[raiuns]

also ich halte mich nicht mit Infos absichtlich bedeckt - ich weiß es schlicht einfach nicht mehr..

Wie gesagt, ich kann die Festplatte mit einem USB-Sata-Adapter an einen Laptop anschließen und ich sehe die Verzeichnisse /etc /home /var etc .. alles da

Inzwischen habe ich auch einen USB-Port gefunden, mit dem ich von einen USB-Stick offenbar ein neues Linux (install-Stick) starten könnte..

Und Inzwischen habe ich auch eine neue, leere, größere Festplatte da.

Was müsstet ihr den wissen, um fgestzustellen, ob man die zweite partition retten kann - bzw. wie finde ich diese Infos?

[raiuns]

Ah ja und natürlich - ich hatte versucht zu booten - aber es blieb bei dem blinkenden cursor - nicht dass er das eigentliche Bild woanders darstellen will?

[fischig]

Soweit's mich betrifft, müsste ich wissen, ob efi benutzt wird oder nicht. Meine Idee mit dem alten bootloader (lilo) funktioniert halt mit efi nicht mehr. Ich glaub' einfach nicht, dass das System lediglich aufgrund eines Stromausfalls nicht mehr funktioniert. Stromausfall ist mir in 20 Jahren Debian nicht nur einmal passiert - und zwar ohne dass der das System wesentlich geschädigt hätte.. Ergo setzte ich zunächst am bootloader an. Dass ich den (grub) nicht besonders mag, dürfte deutlich geworden sein.

ich kann die Festplatte mit einem USB-Sata-Adapter an einen Laptop anschließen und ich sehe die Verzeichnisse /etc /home /var etc .. alles da

Dann solltest du in das System chrooten können.

Der „blinkende“ Cursor am Ende des Bootvorgangs kann auch auf ein Grafikproblem hinweisen (nvidia?); steht vor dem blinkenden Cursor vielleicht sowas wie:

Code: Alles auswählen

[rechnername] login:

, aber auch das hat mit Stromausfall nichts zu tun.

[MSfree]

Ich glaub' einfach nicht, dass das System lediglich aufgrund eines Stromausfalls nicht mehr funktioniert.

Wer weiß, was da mit dem letzten Strompuls noch an Unsinn auf der Festplatte/SSD gelandet ist. Wenn es ausgerechnet die initrd beschädigt hat, würde das Fehlerbild genauso aussehen, wie in diesem Fall. Wenn die initrd beschädigt ist, und danach sieht es mir aus, dann nützt ein anderer Bootloader auch nichts.

Dass ich den (grub) nicht besonders mag, dürfte deutlich geworden sein.

An dem liegt es in diesem Fall aber mit ziemlicher Sicherheit nicht.

Wie gesagt, ich kann die Festplatte mit einem USB-Sata-Adapter an einen Laptop anschließen und ich sehe die Verzeichnisse /etc /home /var etc .. alles da

Inzwischen habe ich auch einen USB-Port gefunden, mit dem ich von einen USB-Stick offenbar ein neues Linux (install-Stick) starten könnte..

Und Inzwischen habe ich auch eine neue, leere, größere Festplatte da.

Ich würde dann tatsächlich Debian auf die neue Platte frisch installieren.

Da du die Daten von der "defekten" Platte lesen kannst, könntest du die auch nach der Neuinstallation rüberkopieren.

Was müsstet ihr den wissen, um fgestzustellen, ob man die zweite partition retten kann - bzw. wie finde ich diese Infos?

Die Frage wäre eher, wie sattelfest du mit Linux bist.

Man könnte die Platte wieder einbauen, ein Rettungssystem über USB booten, dann mit chroot auf das System mit der defekten zweiten Partition wechseln und dort den Kernel neu installieren, was auch gleich die initrd neu erzeugt und grub frisch konfiguriert.

[raiuns]

lach! nein es steht kein "login:" vor dem blinkenden Cursor..

ich werde mal noch etwas weiter eure Tips ausprobieren.

Woran sehe ich "ob UEFI benutzt wird" ?

[raiuns]

Neue Erkenntnis: ich denke, es ist nicht unbedingt die Festplatte, eher ist an dem Board/derGrafikkarte etwas defekt, denn

(ich hab nicht immer gleich Zeit, Dinge auszuprobieren)

Wenn ich jetzt mit einem neuen Ubuntu Boostick boote, egal ob "try Ubuntu" oder "Ubuntu (safe graphics)". lande ich ebenfalls immer nur auf dem blinkenden Cursor - und die "Grafikkarte" ist ja alles onboard.

Also werde ich mich mal nach einem alternativen "alten" Gerät/Board umsehen - oder kann es noch was anderes sein?

[MSfree]

Wenn ich jetzt mit einem neuen Ubuntu Boostick boote, egal ob "try Ubuntu" oder "Ubuntu (safe graphics)". lande ich ebenfalls immer nur auf dem blinkenden Cursor - und die "Grafikkarte" ist ja alles onboard.

Komisch, daß du diese Frage "try Ubuntu" oder "Ubuntu (safe graphics)" noch zu sehen bekommst und das Problem erst nach der Auswahl einer der beiden Optionen auftritt. Ich habe keine Ahnung, welche Voraussetzungen Ubuntu an die Graphik stellt, und ob Ubuntu bestimmte alte Graphikhardware gar nicht mehr unterstützt. Debian läuft bei mir zumindest problemlos, auch mit grapischer Umgebung, auf einem Core2-Q8200 mit Intel Onboardgraphik von 2008.

Ich würde noch versuchen, einen Debian Netinstaller runterzuladen und auf einen USB-Stick zu kopieren:
https://cdimage.debian.org/debian-cd/cu ... etinst.iso

Damit kann man Debian auch komplett ohne graphische Umgebung im reinen Textmodus installieren, was für einen headless Server ohnehin ausreichen sollte.

Also werde ich mich mal nach einem alternativen "alten" Gerät/Board umsehen

Das steht dir natürlich frei. Wenn du aber ohnehin "neue" Hardware beschaffen willst, würde ich nach etwas halbwegs aktuellem suchen, das dann auch noch in ein paar Jahren unterstützt wird. Zu altes Zeug ist letztlich auch nicht besonders sparsam im Stromverbrauch. Der o.g. Core2 zieht z.B. fast 50W aus der Steckdose im Leerlauf, mein normaler Alltagsrechner (Core i5-10400) begnügt sich mit 15W. Ein Intel NUC mit Celeron-N4020 und SATA-SSD braucht sogar nur 3W.

[GregorS]

Also werde ich mich mal nach einem alternativen "alten" Gerät/Board umsehen - oder kann es noch was anderes sein?

Der Effekt mit blinkendem Cursor nach Grub ist mir auch schon begegnet. Letztlich geholfen hat mir, dass ich mich zum Nachdenken auf den Balkon begeben hatte, denn nach der Rückkehr stand dort die Meldung, dass vergeblich auf die Platte gewartet wurde, von der gebootet werden sollte.
Gib Deinem Rechner also mal ein paar Minuten mit blinkendem Cursor. Vielleicht ergibt sich die Erkenntnis, dass es doch an der Platte liegt.

[fischig]

was auch gleich die initrd neu erzeugt und grub frisch konfiguriert.

Und meine Vermutung ist halt, dass er genau das hier in diesem Fall nicht packt, der „große unifizierende bootloader“.

Woran sehe ich "ob UEFI benutzt wird"?

das überschreitet meine Kompetenz.

Und wenn's eh egal ist, ob das existierend System wieder läuft, dann plädierte ich auch für Neuinstallation.