Linux Systemplatte reparieren unter Raspi?

Hi Leute,

ich habe nebenbei ein LM Mate auf einem x86-Rechner am Laufen und dessen Systempartition scheint ein kleinen Problem zu haben. Es führt leider dazu, dass davon nicht mehr Linux hochgestartet werden kann. Wenige Sekunden nach dem Hochfahren erscheint diese Ausgabe:

BusyBox v1.30 (Ubuntu 1:1.30.1-4ubuntu6.4) built-in shell (ash)
Enter 'help' for a list of built-in commands

(initramfs) _

Jetzt habe ich mir gedacht, ob ich die betroffene Partition am Raspi repariert bekomme. Habe irgendwoher die Info, dass es vielleicht am Superblock liegen könnte - und dazu habe ich das hier abgesetzt im Terminal:

pi@RaspiH:~ $ sudo fsck -v /dev/sdb5
fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
/dev/sdb5: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? yes
fsck.ext4: unable to set superblock flags on /dev/sdb5


/dev/sdb5: ********** WARNING: Filesystem still has errors **********

Demzufolge scheint das Filesystem selbst ein Problem zu haben. Gibt es eine Chance, das am Raspi zu beheben? Und wenn ja: wie?

Danke für jede Hilfe!

Äh - der Bootloader ist ok. Wenn ich ihn einschalte, komme ich ins Linux-Bootmenü, wo ich auch das parallel installierte Win-10 booten kann. Das klappt auch.

Allerdings ist Linux auf einer SSD in einem externen USB-Gehäuse installiert. Deswegen dachte ich, es wäre einfacher, das über das vorhandene Linux zu erledigen. Klingt wohl nach einer Ausrede, aber im Moment fehlt es mir an einem freien USB-Stick. Die gehen mir einfach zu oft verloren (oder stecken sich die Leute einfach ein).

_____________

RTFM

Klappt irgendwie auch nicht:

pi@RaspiH:~ $ sudo e2fsck -fpv /dev/sdb5
/dev/sdb5: recovering journal
/dev/sdb5: Superblock needs_recovery flag is clear, but journal has data.
/dev/sdb5: Run journal anyway

/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    (i.e., without -a or -p options)

Und mit dem fsck gehts auch nicht - siehe oben.

Bei welchem Befehl soll das -b möglich sein? Sowohl beim e2fsck als auch beim sync bekomme ich die Meldung, dass es den Parameter nicht gibt.

pi@RaspiH:~ $ sudo e2fsck -fpvb /dev/sdb5

Invalid non-numeric argument to -b ("/dev/sdb5")

pi@RaspiH:~ $ sync -b
sync: Ungültige Option -- b
„sync --help“ liefert weitere Informationen.

RTFM

Tja - lesen ist das Eine, das Gelesene verstehen ist das Andere. Für mich ist das, was da beschrieben wird, nur unverständliches Kauderwelsch. Gedacht vermutlich für System-Administratoren, die wissen, was Sache ist, aber nicht für einen unwissenden Dummy wie mich. Und dann auch noch in einer mir nicht wirklich geläufigen Sprache.

Wird wohl besser sein, wenn ich über den Raspi versuche, die wichtigen Daten zu kopieren, die SSD platt zu machen und ein neues Linux zu installieren. Scheint für mich die einfachste Variante zu sein.

Danke trotzdem.

RTFM

Erstaunliche Aussage, dass Linux möglicherweise nichts für mich wäre. Damit redest Du komplett gegen den Mainstream. Gibt massenhaft Berichte in diversen Medien zum Thema Computer und auch viele Influenzer argumentieren ständig, dass Linux genauso für Anfänger geeignet wäre wie Windows, da man mittlerweile kaum mehr von der Konsole abhängig sein soll. Und im Grunde genommen stimmt das auch.

Deine Übertreibung (ich würde für jeden Tastendruck einen Personal-Tutor benötigen) richtet sich von selbst, sodass ich darauf nichts sagen werde.

Gut möglich, dass ich kurz vor diesem Ereignis einen Fehler gemacht habe. Es ist nun mal so, dass ich den PC nur selten benötige. Zu mindestens 98% reicht mir mein Raspi-400 vollkommen aus. Leider kann der aber nicht mit meinem Drucker. Sprich: Immer, wenn ich etwas drucken möchte, brauch ich den PC. Und immer, wenn es beispielsweise um Bildbearbeitung geht, auch. Und beim letzten Mal, wo Linux noch tat, wurden automatisiert (von mir so eingestellt) eine Menge Updates installiert. Am Ende bat der Rechner um einen Neustart, was ich abgelehnt hatte. Das war ich unter Windows so gewohnt, dass ich nie einen Neustart initiiere, sondern am Ende der Sitzung den Rechner einfach herunter fahren lasse. Und beim nächsten Start soll halt der Rest fertig installiert werden. Nur: LM hatte gestartet, danach saß ich vor einem Monitor, der nur ein schwarzes Bild zeigte. Keinerlei Information darüber, was jetzt gerade passiert. Übrigens: Eine Sache, die ich grundsätzlich nicht verstehe. Windows schreibt wenigstens, dass man den Computer nicht ausschalten solle und es gibt eine Animation, die zeigen soll, dass der Rechner nicht abgestürzt ist. Sowas täte ich mir auch von Linux wünschen; oder sind die Programmierer nicht in der Lage, so zu tun? Egal, nach einigen Minuten ist es mir zu blöde geworden (weil ich vermutete, dass der Rechner abgestürzt wäre) und hab am PC den Einschaltknopf für ein paar Sekunden gedrückt, worauf sich der Rechner abgeschaltet hat. Beim darauffolgenden Booten kam dann die obige Meldung.

Also wenn sowas wirklich "normal" sein soll, dann stimme ich Dir zu, dass LM nix für mich ist. Allerdings: Wie man heute, wo Gott und die Welt den Teufel an die Wand malt, demzufolge es keine Frage sein soll, OB ein europaweiter Blackout kommt, sondern eher, WANN das passieren wird, keine entsprechenden Maßnahmen trifft, die ein unerwartetes Abschalten eines Gerätes zum Totalausfall führen kann, verstehe ich nicht. Unter Windows mache ich das so gut wie bei jedem größeren Update. Und Windows scheint wohl mitzubekommen, dass der Einschaltknopf für mehrere Sekunden gedrückt ist und dürfte dann sofort auf weitere Schreibzugriffe verzichten, weswegen es niemals zu einem Laufwerksproblem kommen kann. Ich vermute, dass das Motherboard in dem Fall ein SIGABORT ans OS sendet. Linux scheint das zu ignorieren.

Egal - ich lasse mich auch nicht durch Deine Worte davon abhalten, künftig Linux zu verwenden. Dafür läuft es grundsätzlich zu gut.

CyPi

Zur Info: Am x86-er Rechner ist die Platte selbstverständlich intern am SATA-Controller angeschlossen. Ich hab - da mir, wie schon geschrieben - im Moment kein USB-Stick zur Verfügung steht, einfach die Platte ausgebaut, in ein externes USB-Gehäuse verfrachtet und am Raspi angesteckt.

Ich vermute, dass Grub sowieso auf dieser SSD abgelegt ist. Das Problem war seinerzeit, dass sich Linux nicht hat installieren lassen, weil der Rechner vom Werk aus auf BIOS lief, LM aber UEFI verlang. Windows ist auf der M.2 SSD installiert und es parallel zu installieren, hat eben nicht geklappt. Also hab ich eine nicht benötigte SATA-SSD angeschlossen, im BIOS UEFI eingestellt und dann konnte ich sowohl LM als auch Grub installieren.

Wie oben geschrieben: ich vermute, dass der Rechner einfach den Strom abgeschaltet hat, während LM gerade auf die SSD geschrieben hat. Ist eben blöde, wenn man vor einem schwarzen Monitorbild sitzt und keinerlei Information bekommt, ob der Rechner gerade etwas tut und wenn, was genau er tut. Leider hat der Mini-PC auch keine LED, die darüber Auskunft gibt, ob gerade auf ein Laufwerk zugegriffen wird. Für mich sah es so aus, als ob der Rechner eben tot wäre. War er vermutlich doch nicht.

Naja, blöd gelaufen und etwas für die Zukunft mitgenommen. Aber im Grunde genommen ist es nicht so schlimm, weil wie oben schon geschrieben: mein eigentliches Produktiv-System ist der Raspi. Unter diesem Linux gibt es nur wenige Dateien, die wichtig sind. Wäre zudem eine gute Gelegenheit, gleich auf das neueste LM umzusteigen.

Ok, wenn wir gerade Korinthenkacken sind:

Gemäß DeepL wird "UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY." so übersetzt: "Unerwartete Inkonsistenz; fsck manuell ausführen."

Was für mich nach einer Aufforderung klingt, fsck auszuführen und nicht e2fsck.

Ganz ehrlich? Wenn ich das "p" (was übrigens von Dir vorgegeben wurde) einfach weglassen soll, weil die Kombination mit dem f und dem v inkonsistent ist, dann erwarte ich, dass er mir sagt, dass die Kombination aus f und p und v nicht konsistent ist. Genau das meinte ich, als ich sagte, dass unter Linux nur mit Stichworten herum geworfen wird. Statt dass man in ganzen und verständlichen Sätzen zu mir spricht.

Ja, ich weiß, dass Du nicht verantwortlich bist dafür, dass die Fehlermeldungen so erfolgen, wie sie es nun mal tun. Aber Du bist offensichtlich jemand, der diesen Umstand mir gegenüber verteidigt. Du hättest auch sagen können: "Stimmt, das ist wirklich blöde, weil nicht eindeutig klar verständlich" und mir mit ruhigen Worten erklären können, wie die Fehlermeldung zu verstehen ist. Ein "Read the fucking manual" hilft da natürlich deutlich mehr! Danke schön!

Quote from Fliegenhals

@ralfi1988

K.A. wie Du das Update von deinem LM durchgeführt hast, egal ob grafisch oder im Terminal, es gibt immer eine Fortschrittsanzeige und manche Dinge dauern halt je nach Bandbreite der Internetverbindung bzw. PC Rechenleistung etwas.

Tut mir leid, wenn ich widerspreche. Es gibt eben NICHT immer eine Fortschrittsanzeige. Wenn man das System so eingestellt hat, dass die Updates automatisch installiert werden (also ähnlich wie unter Windows), dann sieht man gar nichts; man muss nicht mal ein Passwort eingeben. Lediglich dann, wenn nach dem Einspielen der Updates ein Neustart erforderlich ist, erscheint ein Info-Fenster, welches geduldig auf das Abnicken des Reboots wartet. Und selbst dieses Info-Fenster erscheint nicht im Vordergrund, sondern liegt ganz unten, unter allen anderen Fenstern, die gerade am Desktop liegen. Und es ist auch nicht in der Leiste sichtbar. Sprich: Als einfacher Anwender bekommt man das in der Regel gar nicht mit, wenn Updates installiert werden.

fred0815

Fehlt bei Deinem Vorschlag nicht die Angabe des Laufwerks? Oder wie sonst weiß der Raspi, welche der beiden SSDs gemeint ist?

Bei mir sieht der dumpe2fs ähnlich aus:

:
Group 0: (Blocks 0-32767) csum 0x7d8a [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-14
  Reserved GDT blocks at 15-1038
  Block bitmap at 1039 (+1039), csum 0x2110c0c0
  Inode bitmap at 1055 (+1055), csum 0x906ab355
  Inode table at 1071-1582 (+1071)
  21012 free blocks, 8174 free inodes, 2 directories, 8174 unused inodes
  Free blocks: 9300-9301, 9312-9327, 9331, 9335-9343, 9346-9347, 9376-9407, 9425
, 9430-9447, 9472-9727, 9737, 9739-9743, 9752-9759, 9762-9776, 9790-9870, 9872-9
884, 9886-9951, 9974-9976, 9981-10023, 10031-10168, 10575-10751, 11032-14783, 15
266-15656, 15658-15810, 15814, 15816-15837, 15841-15855, 15873, 15877-15906, 163
83-24575, 25201-32767
  Free inodes: 19-8192
Group 1: (Blocks 32768-65535) csum 0xbce1 [INODE_UNINIT, ITABLE_ZEROED]
  Backup superblock at 32768, Group descriptors at 32769-32782
  Reserved GDT blocks at 32783-33806
  Block bitmap at 1040 (bg #0 + 1040), csum 0x5c4eae47
  Inode bitmap at 1056 (bg #0 + 1056), csum 0x00000000
  Inode table at 1583-2094 (bg #0 + 1583)
  536 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
  Free blocks: 33845-33847, 33888-33915, 33917, 33919, 33983, 34040-34047, 34072
-34097, 34104-34111, 34161, 34164-34175, 34211-34301, 34305-34317, 34319-34349, 
34351-34381, 34385-34390, 34392-34399, 34432-34434, 34436-34442, 34444-34454, 34
456-34471, 34474-34475, 34477-34502, 34504, 34506-34548, 34550-34554, 34556, 345
58-34562, 34564-34567, 34569-34585, 34587-34589, 34591-34597, 34602-34606, 34608
-34616, 34619-34623, 34665-34687, 34719, 34743-34815
  Free inodes: 8193-16384
Group 2: (Blocks 65536-98303) csum 0xd718 [INODE_UNINIT, ITABLE_ZEROED]
  Block bitmap at 1041 (bg #0 + 1041), csum 0xdfcec6e0
  Inode bitmap at 1057 (bg #0 + 1057), csum 0x00000000
  Inode table at 2095-2606 (bg #0 + 2095)
  0 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
  Free blocks: 
  Free inodes: 16385-24576
:
:

Kein Problem - mitunter fällt sogar mir sowas auf ...

Habs mal probiert, aber es hilft alles nichts: das Laufwerk mag offensichtlich nicht mehr. Hier das Ergebnis:

pi@RaspiH:~ $ sudo e2fsck -y -v -f -b 32768 /dev/sdb5
e2fsck 1.46.2 (28-Feb-2021)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdb5: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
e2fsck: unable to set superblock flags on /dev/sdb5


/dev/sdb5: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb5: ********** WARNING: Filesystem still has errors **********

Gibt es unter Linux kein Tool, welches hardwareseitig das Laufwerk überprüft? Also Sektor für Sektor ausliest und etwaige Fehler auswirft? Das wäre zumindest mal ein Ansatz, herauszufinden, ob die Hardware noch ok ist ...