Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
19.09.2020, 17:54:09

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
Statistiken
  • Beiträge insgesamt: 683205
  • Themen insgesamt: 55317
  • Heute online: 348
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema: [erledigt] Zweimal Systemcrash in 4 Wochen, dann Boot-Repair und nun geht gar nichts mehr .  (Gelesen 461 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Linux Mint 20 Cinnamon
Laptop ASUS PRO 2530UA; Intel Core i5

Laufwerke:
sda: Laptop, 1 TB Festplatte
sda1: EFI System Partition;
sda2: Root
sda4: HOME

sdb:
USB 3-Stick Kingston DataTraveler 3.0, "Multiboot UEFI" (LM 19.3 + LM 20);

sdc:  externe FP Intenso, USB 3.0, 4 TB;

sdd:
externe FP WD Elements 25A3, USB 3.0, 8 TB
sdd1: 6.7 TB Microsoft basic data
sdd2: 616.1 GB Linux FS

sde:  USB 3-Stick Platinum, "GPARTED-LIVE", 4 GB, 266 MB belegt


Hallo, ich war in den letzten Jahren eher stiller Mitleser. Aufgrund von zwei Systemcrashs innerhalb weniger Wochen komme ich aktuell nicht weiter und hoffe, daß mir von dem einen oder anderen Forumsuser weitergeholfden werden kann.

Ich habe mich Mitte 2016 entschieden auf Linux umzusteigen. Da ich reiner Anwender war (und auch noch bin), bat ich um Vorschläge eines geeigneten Linux-OS für den Umstieg von Windows 7. Wobei ich vorhatte, auf meinem Desktop-PC vorerst weiter mit Win 7 zu arbeiten und mir zusätzlich ein refurbished Notebook mit vorinstalliertem Linux OS anzuschaffen. Als Betriebssystem wurde mir hauptsächlich MINT 18 empfohlen, für die Hardware rieten mir Freunde zu ix-soft in Brandenburg, die gebrauchte Noteboooks aufarbeiten und mit einem Linux-OS nach Wunsch vorinstallieren.

Okay, ich kaufte dann auch ein ASUS-Laptop mit 1 TB 2.5" HD, 8 GB RAM sowie MINT 18.3 Cinnamon. Das lief auch alles ohne Beanstandungen bis April 2020, also immerhin ca. 3½ Jahre. Aus verschiedenen Gründen zog sich das bis Mitte/Ende Juli hin. Da Mitte Juli auch schon LM 20 cinnamon veröffentlicht wurde, entschied ich mich für eone Neuinstallation je einen USB-Multiboot-Stick mit LM 19.3 + LM 20 cinnamon jeweils für UEFI- und alternativ Legacy-Modus fertigzustellen, da ich zum einen nicht wußte ob die LM 20 Cinnamon-Installation akzeptiert wird und zum anderen, ob die Installation in UEFI klappen würde.
Okay, die Installation von LM 20 cinnamon war erfolgreich, ebenso die Installation in UEFI, secure boot hatte ich vorher abgeschaltet. Ich hatte zwar schon eine externe FP mit 4 TB Kapazität, aber da die externe FP-Kapazität etwas knapp werden könnte, legte ic mir noch eine zweite externe FP mit eine Kapazität von weiteren 8 TB zu.

Es kam dann wohl, wie es kommen mußte. Kaum 4 Wochen später stürzte der Laptop wieder ab. Da ich bei der Installation auf der FP des Laptops ein separates Home-Verzeichnis von fast 600 gebildet hatte, hätte ich ja einfach neu installieren können.Aber ich hatte entweder LM 20 Live oder GPARTED-LIVE aktiv und da muß das Programm boot-repair dabei gewesen sein. Es wäre eine gute Idee gewesen, wenn die Erfahrungen anderer User mit diesem Programm gegoogtlet hätte. Aber ich habe dieses Programm gestartet und dachte es macht, was es tun sollte. Offensichtlich habe die den Legacy Mode wieder ins Spiel gebracht, denn  ich bekam eine Meldung:

Bios von folgender Datei starten:
sda1/EFI/ubuntu/shimx64.efi

Dazu schrieben sie mir noch, daß sie den Ablauf des Programms boot-repair bzw. das Protokoll davon auf paste.ubunti hochgeladen. Hier ist die Adresse, die allerdings jetzt nur noch bis 18.09.20 verfügbar ist:
https://paste.ubuntu.com/p/bpgGCZw7h7/

Ich habe den Text in folgenden Formaten abgespeichert: *.txt; *.docx; *.odt; *.rtf; *.pdf; *.html; *.pdf
Alle Dateien habe ich als "Boot-Repair-Info-20200818.7z" gepackt und auf mein Konto bei pCloud hochgeladen.

Direktlink:
https://filedn.com/l4e4QEToxV3mOCa42M7Cuub/boot-repair/Boot-Repair-Info-20200818.7z


Laufwerke, die in dem boot-repair-Protokoll angesprochen werden. Die Partitionen sind in dem Proitokoll ja separat aufgeführt.

Ich hoffe, ich habe keine Informationen vergessen (?)!

Besten Dank im voraus für die Unterstützung!
« Letzte Änderung: 17.09.2020, 16:16:43 von cajunX »

Ich hätte als erstes mal die S.M.A.R.T. Werte der Festplatte überprüft und zusätzlich mal den Arbeitsspeicher mit MemTest o.ä.

Abstürze deuten gerne auch mal auf Hardwareprobleme hin.

Hylli


Wenn das RAM ziemlich unten ist und ich lade es dann wieder auf, dann hört es bei 89% auf mit Laden. Lese- und/oder Schreibfehler könnten auch möglich sein. Ich will beides mal durchtesten. Danke für die Antwort.

Wenn das RAM ziemlich unten ist und ich lade es dann wieder auf, dann hört es bei 89% auf mit Laden.
?? Was meinst du damit denn? Noch nie gehört, dass man was anderes als den Akku aufladen kann. ;)

Klar, der Ladezustand wir in % angezeigt. Und wenn der Akku zu 89-90% aufgeladen wurde, geht die Anzeige nicht weiter hoch. Ich weiß jetzt nicht ob der Akku nicht ganz intakt ist oder ob die Anzeige der Aufladung nicht stimmt.

Die Ladekapazität von Akkus lässt mit der Zeit nach. Dann kann ein Akku nicht mehr auf  100% geladen werden. 89-90% scheint mir noch ein ganz passabler Wert zu sein.

Mir ist allerdings auch nicht klar geworden, wo du da die Verbindung zum RAM und zu den Systemabstürzen siehst?
« Letzte Änderung: 16.09.2020, 15:38:45 von Parmenides »

Random Accu Memory?

hylli  ;D

Keine Ahnung wieso ich da auf RAM gekommen bin. Es ist mit dem Akku so, daß ich irgendwann gemerkt habe, daß der Akku nur noch bis 89-90% lädt. Auf dem Level ist es alllerdings auch seit langem konstant. Okay, kann ich abhaken.

Ich habe gestern nochmal versucht, mit einem Live-Stick Zugriff auf die Festplatte zu bekommen. Das Problem liegt wohl bei sda4 (Home-Verzeichnis), das mit knapp 600 GB allerdings auch der grösste Brocken ist. Beim Versuch, sda zu mounten, bekomme ich die Meldung "Der Superblock von /dev/sda4 konnte nicht gelesen werden."
Entsprechend kann ich wohl auf sda1 und sda2 zugreifen, aber eben nicht auf sda4. Dasselbe zeigt ja im Prinzip auch der gepostete Reprt von repair-boot:
Zeilen 1869 ff.

mount: /mnt/boot-sav/sda4: Der Superblock von /dev/sda4 konnte nicht gelesen werden.
mount /dev/sda4 : Error code 32
mount -r /dev/sda4 /mnt/boot-sav/sda4
mount: /mnt/boot-sav/sda4: Der Superblock von /dev/sda4 konnte nicht gelesen werden.
mount -r /dev/sda4 : Error code 32

Möglicherweise ist die FP der Schlüssel. Ich werde noch etwas warten und dann evtl. die Firma kontaktieren, die den Laptop verkauft hat. Neue FP rein, aber da muß natürlich sichergestellt sein, daß da nicht in einem halben Jahr ein anderes Faß aufgemacht wird. Gegebenenfalls eben einen neuen Laptop kaufen und in Kauf nehmen, daß die Dateien von der Home Partition, die noch nicht gesichert sind, dann weg sind.

Du kannst selber feststellen, ob da ein Plattenfehler vorliegt oder nur ein möglicherweise selbst verursachter (reparabler) Dateisystemschaden.

Mit "Laufwerke" kannst du dir die SMART Werte anzeigen lassen. Und auch versuchen, das Dateisystem zu reparieren (von einem Livesystem aus).
« Letzte Änderung: 17.09.2020, 12:56:16 von toffifee »

Guten Tag,
ich hatte mal ein ähnliches Problem eventuell hilft dir das weiter: https://www.linuxmintusers.de/index.php?topic=57940.msg791101#msg791101
Du solltest aber zuerst bei gparted >Partition markieren< "Gerät"->"Datenrettung versuchen" ausführen. Die Partition muss ausgehängt sein, aber das ist sie bei dir ja sowieso. Oder? 
Gruß
Wolfgang
« Letzte Änderung: 17.09.2020, 12:22:12 von Wolfgang58 »

@toffifee
Danke, dann schaue ich nochmal. Ich habe neben dem LM 20 Live-Stick noch einen USB-Stick mit GParted Live. Soll ich mit dem am besten hochfahren? Dann probiere ich das mal.

@Wolfgang
Ich schau mir mal den von Dir angeführten Thread an. Ich habe nen GParted Live Stick und hoffe, daß mir das weiterhilft.


Danke an Euch beide für die Ratschläge!

Fahr LM20 vom Stick hoch, dann hast du auch gparted...

Ich kann es zwar noch immer nicht ganz fassen, aber das ging mit gparted ratz-fatz und gleich beim ersten Versuch hat der Rechner gebootet - wenn es auch ne ziemliche Zeit dauerte ...

Okay, soweit war ich im Juli ja auch schon mal nach der ersten LM 20-Installation und vier Wochen später wars wieder dunkel. ;) Jetzt muss man einfach mal sehen ob sich in den nächsten Wochen/Monaten weitere Lesefehler bei der FP zeigen. Falls ja, wird irgendwann eben doch eine neue HD fällig sein.
Fürs Erste freue ich mich einfach, dass das Dingen wieder bootet und nochmal meinen besten Dank für Euere Hilfe!