Mein Laptop hat eine SSD mit Windows und Linux, sowie eine HDD für Medien. Gestern habe ich Debian 10 Buster (stable) auf Version 11 Bullseye (testing) aktualisiert. Das klappt weitgehend problemlos, nur mit VirtualBox (Fremdsoftware) hatte ich ein bisschen zu kämpfen. Ich habe den Rechner gestern zweimal erfolgreich rebootet. Einmal weil ich musste und ein zweites mal als abschließenden Test. Heute morgen startete er nicht mehr. Fehlermeldung war, dass meine Medien-Partition auf der HDD nicht gemounted werden kann, weil sie kein gültiges ext4 Filesystem enthält. Also habe ich das root Passwort für den abgesicherten Modus eingetippt und es manuell versucht - keine Chance. Dann habe ich nochmal den mit dem alten Kernel gebootet, was tadellos klappte (gut das das bei Linux geht). Die Partition wurde gemounted und ich konnte problemlos darauf zugreifen. Ohne Fehlermeldung, ohne Warnung. Weil ich keinen Fehler gefunden habe, bootete ich also wieder mit dem neuen Kernel von Debian 11. Dieses mal kam keine Fehlermeldung mehr. Ich habe das dann noch ein paar mal mit Kalt- und Warmstart wiederholt. Der Fehler ist nicht wieder aufgetreten. Während der ganze Aktion habe ich keine ungewöhnlichen Geräusche wahrgenommen. Der Laptop hat ganz normal gerauscht, wie immer. Wenn die Festplatte nicht angelaufen wäre, hätte ich das ganz sicher gehört, denn die ist lauter als der Lüfter (außer beim Spielen). Ich frische jetzt sicherheitshalber mal beim Backup auf. Hat jemand eine Idee, was das gewesen sein könnte?
Stefan ⛄ F. schrieb: > Hat jemand eine Idee, was das gewesen sein könnte? Hast Du die Fehlermeldungen mit dmesg angesehen und abgelegt? Daraus müßte mehr zu schließen sein. Es gab eine Zeil lang ein Problem mit Ext4 und Ext3 auf USB-Sticks an unterschiedlichen Rechnern. Das Filesystem bekam eine Erweiterung verpaßt durch eine neue Version, die der andere nicht lesen konnte. Ein fsck schmiss daher alle Dateien weg, die gändert wurden. Könnte bei Dir ein ähnliches Problem gewesen sein.
Was mir dazu als erstes einfällt (weil schon gehabt): Wackelkontakt am HD Kabel. Ansonsten: syslog.
:
Bearbeitet durch User
Dieter D. schrieb: > Hast Du die Fehlermeldungen mit dmesg angesehen und abgelegt? Natürlich nicht, daran dachte ich erst zu spät (typisch). Ich habe mal Auszüge aus dem kern.log und syslog angehängt. sdb2 ist meine swap Partition auf der HDD sdb3 ist meine Medien Partition (ext4) auf der HDD 08:12 Fehlstart neuer Kernel 08:15 erfolgreicher Start alter Kernel 08:40 erfolgreicher Start neuer kernel Das waren meine ersten drei Startversuche heute morgen. Obwohl auf der Konsole erschien, dass meine Partition kaputt sei, sagt das kernel Logfile von 8:12 aber, dass die beiden Partitionen erfolgreich gemounted wurden. Diese "spurious data" Fehlermeldungen sind nicht neu, sie kommen jeden Tag 1-3 mal vor. Im Syslog von 8:12 finde ich sdb3 gar nicht, deswegen habe ich hier mal ausnahmsweise alle Meldungen aus dem Zeitraum angehängt. In den beiden anderen syslog Files finde ich Meldungen zu sdb3. Die eigentliche Fehlerursache kann ich an den Logs nicht erkennen. genau genommen sehe nicht einmal eine Fehlermeldung bezüglich sdb oder sdb3. Hast du vielleicht noch einen Tipp, wonach man suchen könnte? (nach "error" habe ich schon gesucht, nichts relevantes gefunden).
Stefan ⛄ F. schrieb: > Hast du vielleicht noch einen Tipp, wonach man suchen könnte? (nach > "error" habe ich schon gesucht, nichts relevantes gefunden). Das ist anscheinend ein Henne-Ei-Problem in Verbindung mit der Optimierung, dass Linux schneller startet. Ich erinnere mich beim Informatiker eine Kritik zu Linux gelesen zu haben, dass innerhalb von /sys /run /var dev usw. in Verbindung mit dem neuen Kernel wieder etwas umgestellt wurde. Der neue Kernel macht einen Neustart, liest aus was er findet. Die neuen gänderte Verzeichnisse werden zwar geschrieben, die Inhalte in der Form der neuen Struktur zur Hardware standen beim ersten Schnellboot nicht zur Verfügung. Der alte, aber aktualisierte Kernel kann aber mit den Strukturen des vorherigen Kernels umgehen und bekam Erweiterungen, dass der die neuen Strukturen verwenden kann, sofern diese gesichtet werden. Das scheint der alte Kernel gemacht zu haben, bzw. die Eintragungen sind durch diesen nun drinnen und das Henne/Ei-Problem ist dadurch nun weg. Genau genommen hätte man verschiedene Infos in dem Zustand mit hdparm herausgraben müssen, mit mount manuell noch ein paar Fehlermeldungen generieren müssen und auch mit "debugging" aufrufen sollen. Eine Methode wäre zum Beispiel: https://www.tecmint.com/strace-commands-for-troubleshooting-and-debugging-linux/ Da kann man aber viel Zeit für die Suche versenken. Instinktiv fandest Du bereits eine einfache Lösung, die das automatisch erledigte.
lass mal die long-Tests der smartmontools über beide Platten laufen
Was passiert, wenn Du den Rechner ganz ausschaltest (also vom Netz nimmst) und dann wieder hochfährst?
bingo schrieb: > Was passiert, wenn Du den Rechner ganz ausschaltest (also vom Netz > nimmst) und dann wieder hochfährst? Er startet erfolgreich. bingo schrieb: > lass mal die long-Tests der smartmontools über beide Platten laufen Mache ich. Habe ein bisschen Schiss, dass die HDD eine Macke hat. Ich hätte Logs vom Fehler sichern sollen, aber da der zweite Startversuch schon wieder klappte, habe diese eine Chance verpasst. Aber falls es sich wiederholt, mache ich das. Was strace angeht: Kenne ich aber ich traue mir nicht zu, mount und alles was da dran hängt zu debuggen. Bei eigenen Programmen ist das was anderes.
Stefan ⛄ F. schrieb: > Ich hätte Logs vom Fehler sichern sollen, aber da der zweite ... Einige Fehlermeldungen sind in der Regel noch vorhanden. /var/log $ ls kern.log kern.log.1 kern.log.2.gz usw. syslog.log syslog.log.1 syslog.log.2.gz usw. Aus diesen hattest Du heute bereits gepostet.
Stefan ⛄ F. schrieb: > Heute morgen startete er nicht mehr. Fehlermeldung war, dass meine > Medien-Partition auf der HDD nicht gemounted werden kann, weil sie kein > gültiges ext4 Filesystem enthält. Warum startet Linux nicht mehr, wenn eine optionale Partition nicht gemountet werden kann? Die ist doch für den Betrieb nicht nötig?
Hallo Stefan, Stefan ⛄ F. schrieb: > Mache ich. Habe ein bisschen Schiss, dass die HDD eine Macke hat. zeig' mal mit smartmontools die SMART-Parameter der verdächtigen Festplatte: smartctl -a /dev/sdX > stefan.txt Ersetze X durch den Laufwerksbuchstaben der verdächtigen Platte.
>Heute morgen startete er nicht mehr. Fehlermeldung war, dass meine >Medien-Partition auf der HDD nicht gemounted werden kann, weil sie kein >gültiges ext4 Filesystem enthält. Also habe ich das root Passwort für >den abgesicherten Modus eingetippt und es manuell versucht - keine >Chance. >Dann habe ich nochmal den mit dem alten Kernel gebootet, was tadellos >klappte (gut das das bei Linux geht)." Bei so einem Verhalten wäre mein erster Verdacht eine falsch generierte initrd - wenn nicht, wie von anderen Postern bereits beschrieben, ein Treiberbug.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Gestern habe ich Debian 10 Buster (stable) auf Version 11 Bullseye > (testing) aktualisiert. .... > Ich frische jetzt sicherheitshalber mal beim Backup auf. Die Reihenfolge ist hier etwas suboptimal ;-)
Stefan ⛄ F. schrieb: > Heute morgen startete er nicht mehr. Reinhard S. schrieb: > Warum startet Linux nicht mehr, wenn eine optionale Partition nicht > gemountet werden kann? Die ist doch für den Betrieb nicht nötig? Sorry, da habe ich mich falsch ausgedrückt. Er hat bei starten an der Stelle pausiert, wo das Mounten der Partition fehlschlug. An der Stelle konnte Ctrl-D drücken, um trotzdem fortzufahren. Also gebootet hat er schon.
Peter M. schrieb: > zeig' mal mit smartmontools die SMART-Parameter der verdächtigen > Festplatte: > > smartctl -a /dev/sdX > stefan.txt
Andy D. schrieb: > Bei so einem Verhalten wäre mein erster Verdacht eine falsch generierte > initrd - wenn nicht, wie von anderen Postern bereits beschrieben, ein > Treiberbug. Das war auch mein erster Verdacht. Aber der zweite Bootversuch ging ja dann doch, ohne dass ich irgend etwas verändert hatte.
Jam S. schrieb: > Die Reihenfolge ist hier etwas suboptimal ;-) Ja stimmt. Das vorherige Backup ist eine Woche alt. Ich vertraue der Stabilität von Linux inzwischen so sehr, dass ich diesbezüglich sehr schlampig geworden bin.
Stefan ⛄ F. schrieb: > Debian 10 Buster (stable) auf Version 11 Bullseye (testing) Kleine Bugs bei initrd oder Treiber sind durchaus auch möglich. Er hat ja auch aktualisiert auf eine Testing-Version. Das ist es auch überhaupt nicht überraschend, dass nicht alles ganz zickenlos funktioniert. Die Sonderroutinen des Schnellstarts husten da ganz gerne mal.
Reinhard S. schrieb: > Warum startet Linux nicht mehr, wenn eine optionale Partition nicht > gemountet werden kann? Die ist doch für den Betrieb nicht nötig? Ob die Platte optional ist wird in /etc/fstab festgelegt. Du kannst das System von einer Linux Live CD starten und dann die Datei bearbeiten. Bei der Gelegenheit kannst du dann auch gleich einen fsck ausführen, der das Problem (wahrscheinlich) behebt. https://de.wikipedia.org/wiki/Fstab Schlüssel ist der Parameter "Pass". Du solltest ihn für die Medienplatte auf 2 stellen.
dave4 schrieb: > Ob die Platte optional ist wird in /etc/fstab festgelegt. > Du kannst das System von einer Linux Live CD starten und dann die Datei > bearbeiten. Nicht Nötig, die boot SSD war ja heile. Im Fehlerfall habe ich die Wahl zwischen "weiter booten" und "abgesicherter Modus mit root login". dave4 schrieb: > Schlüssel ist der Parameter "Pass". Du solltest ihn für die Medienplatte > auf 2 stellen. Guter Hinweis, den kannte ich aber schon. Steht schon auf 2.
Hallo Stefan, den Fehler mit der Nr. 187 habe ich bei mir noch nicht gesehen. 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 8590000128 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 524288 Meine Empfehlung: Duplizier die Platte mit ddrescue und melde Dich, wenn der Fehler noch einmal auftaucht.
laut https://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes ist der Fehler 187 kritisch!
Aber wenn die Platte wirklich über 500.000 Timeouts und 8 Milliarden Lesefehler hatte, dann hätte das doch längst auffallen müssen. Die Zahlen haben sich bis jetzt übrigens nicht geändert. Ich spiele jetzt mal Videos ab und melde mich dann nochmal.
Bis jetzt haben sich die beiden Zahlen nicht geändert und auch dmesg gibt nichts relevantes aus. In der Spezifikation der Festplatte habe ich eine Liste gefunden:
1 | The device supports following Attribute ID Numbers: |
2 | 9 Power-On Hours Count |
3 | 10 Spin Retry Count |
4 | 12 Device Power Cycle Count |
5 | 160 Free-fall Sensor Self Test Result |
6 | 191 G Sense error rate |
7 | 192 Power off retract count |
8 | 193 Load/Unload cycle count |
9 | 194 Device Temperature |
10 | 196 Reallocation Event Count |
11 | 197 Current Pending Sector Count |
12 | 198 Off-Line Scan Uncorrectable Sector Count |
13 | 199 Ultra DMA CRC Error Count |
14 | 223 Load Retry Count |
15 | 254 Free-fall Sensor Work Count |
Stefan ⛄ F. schrieb: > Aber wenn die Platte wirklich über 500.000 Timeouts und 8 Milliarden > Lesefehler hatte, dann hätte das doch längst auffallen müssen. Das ist ein RAW Wert - wenn Du nicht weißt wie der Hersteller die Information codiert hat, kannst Du damit nichts anfangen. Das kann z.B. ein 32bit Wort sein, in dessen ersten 8 Bits irgendeine Zusatzinfo steckt. Dann bekommst Du große Zahlen und einen Schrecken. Was zählt sind aber die "normalisierten" Werte (Spalte VALUE). Die fangen bei 100 an (manchmal auch bei 200) und werden bei Fehlerereignissen runtergezählt bis sie unter dem Threshold landen - spätestens dann wird's kritisch. Ich sehe bei Deiner Platte kein Problem. Aber wenn Du willst, kannst Du ja mal einen extended self-test machen.
Hallo Np R., Np R. schrieb: > Was zählt sind aber die "normalisierten" Werte (Spalte VALUE). Die > fangen bei 100 an (manchmal auch bei 200) und werden bei > Fehlerereignissen runtergezählt bis sie unter dem Threshold landen - > spätestens dann wird's kritisch. das bestreite ich! :)
Peter M. schrieb: > das bestreite ich! :) Was genau möchtest Du wie korrigieren? - dass die normalisierten Werte bei 100, 200 oder manchmal auch bei 253 anfangen? - dass sie in der Regel runtergezählt werden? - dass sich der Threshold auf die normalisierten Werte bezieht? - dass der Threshold in aller Regel /unter/schritten werden muss (eben weil der normalisierte Wert bei Fehlern sinkt, nicht steigt)?
Np R. schrieb: > Peter M. schrieb: >> das bestreite ich! :) > Was genau möchtest Du wie korrigieren? > - dass die normalisierten Werte bei 100, 200 oder manchmal auch bei 253 > anfangen? > - dass sie in der Regel runtergezählt werden? > - dass sich der Threshold auf die normalisierten Werte bezieht? > - dass der Threshold in aller Regel /unter/schritten werden muss (eben > weil der normalisierte Wert bei Fehlern sinkt, nicht steigt)? Ich schaue mir die normalisierten Werte gar nicht an - nur die Rohwerte, und die nur für ausgewählte Parameter und die anderen nur, wenn Sie auffällig erscheinen.
:
Bearbeitet durch User
Np R. schrieb: > Was zählt sind aber die "normalisierten" Werte (Spalte VALUE). Die > fangen bei 100 an (manchmal auch bei 200) und werden bei > Fehlerereignissen runtergezählt bis sie unter dem Threshold landen Ach so ist das gedacht! Mit dieser Info sehen die Werte für mich deutlich plausibler aus, also vorher. Danke
Peter M. schrieb: > Ich schaue mir die normalisierten Werte gar nicht an - nur die Rohwerte, Das kann gut gehen - oder auch nicht. Manchmal kann man die Rohwerte direkt lesen, bei einigen Werten/Herstellern immer. Aber manchmal eben nicht. Bei Stefans Platte sind es garantiert keine 500.000 Timeouts und 8 Milliarden Lesefehler. Da ist in den Datenfeldern an der entsprechenden Adresse noch etwas anders mit verwurstet. Sonst wäre der normalisierte Wert nicht bei 100. Wenn man etwas sucht, kann man vielleicht herausfinden, wie Hitachi die Rohdaten zu ID 187 formatiert/kodiert und was da noch drinsteckt. Dazu war ich jetzt zu faul. ;-)
Stefan ⛄ F. schrieb: > Im Syslog von 8:12 finde ich sdb3 gar nicht Wut? Dec 5 08:12:54 stefanpc kernel: [ 6.442927] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null) Das dauerte halt mehr als sechs Sekunden. Zwei Sekunden davor: Dec 5 08:12:54 stefanpc kernel: [ 4.682723] WARNING: CPU: 2 PID: 368 at drivers/misc/lis3lv02d/lis3lv02d.c:239 lis3lv02d_get_pwron_wait+0xa3/0xb0 [lis3lv02d] "pwron_wait" deshalb, weil die Platte nach ihrem spinup auch ja erst noch ihre eigene Firmware lesen und ihren eigenen Controller "booten" muss. Das kann manchmal, wie hier, etwas länger dauern. Das könnte (bitte, bevor hier deswegen eine Riesendiskussion losgetreten wird, _ich behaupte nicht das dieses hier der Grund sein muss_) auch am Netzteil oder dessen 12V-Verkabelung (Motorstrom) liegen. Könnte auch am Lageröl (#sticky) der Platte liegen, #Temperatur #Thixotropie. --- Der frühe Vogel fängt den Wurm: Dec 5 08:40:31 stefanpc kernel: [ 4.339970] WARNING: CPU: 7 PID: 292 at drivers/misc/lis3lv02d/lis3lv02d.c:226 lis3lv02d_get_pwron_wait+0xa1/0xb0 [lis3lv02d] Dec 5 08:40:31 stefanpc kernel: [ 5.142249] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null) Das ging dann etwa eineinhalb Sekunden schneller. Darauf würde ich in nächster Zeit mal achten. > Ich frische jetzt sicherheitshalber mal beim Backup auf. :D:D:D
Das ist ein interessanter Hinweis. Auf das Timing hatte ich noch gar nicht geachtet.
Das mit dem langsamen Anlaufen der Platte könnte passen: ich habe auch einige HGST-Travelstar verbaut und da kommt es immer wieder mal vor, dass der Rechner beim booten hängt und erst nach drücken des Reset Knopfes sauber startet. Kommt allerdings auch manchmal bei einer SSD (Crucial MX500) vor, da kann ich mir das weniger erklären. Netzteil habe ich mal überprüft, die Spannungen sind ok und haben auch keinen Dip beim hochfahren.
Peter M. schrieb: > Ich schaue mir die normalisierten Werte gar nicht an - nur die Rohwerte, > und die nur für ausgewählte Parameter und die anderen nur, wenn Sie > auffällig erscheinen. Im Prinzip mache ich das auch so. Das Problem bei SMART ist allerdings, dass eben jeder Hersteller da machen kann, was er will und der Rohwert deshalb mit Vorsicht zu genießen ist. Diese "normalisierten" Werte sollen wohl angeben, wieviel im Bezug auf diesen Wert noch von der Lebensdauer der Festplatte übrig ist. Das ist nicht bei jedem der SMART-Werte wirklich sinnvoll.
Stephan S. schrieb: > Das mit dem langsamen Anlaufen der Platte könnte passen: Der Schnellstart bei Linux hat in solchen Feallen sicherlich Nachteile. Die smart- Routine macht ab und zu einen etwas laengeren Selbsttest, der ein bis zwei Sekunden dauert beim Einschalten der Festplatte. Das machen nicht viele so.
Ich hatte vor einiger Zeit ein ähnliches Problem: Mein Laptop hat eine SSD (sda, mit Boot- und Root-Partition) und eine HDD (sdb, mit Var-, Swap- und Home-Partition). Irgendwann bootete der Rechner nicht mehr und zeigte irgendwelche Mount-Probleme an. Nach einem Reboot funktionierte wieder alles, aber alle paar Tage wiederholte sich dieses Spiel aufs Neue. Ich dachte zuerst an einen Hardwarefehler. Als ich die Sache aber näher untersuchte, stellte ich fest, dass im Fehlerfall die Devicenamen der beiden Disks (sda und sdb) vertauscht waren, so dass beim Mounten der Root-Partition statt auf die SSD auf die HDD zugegriffen wurde, wo an der entsprechenden Partitionsnummer die Swap-Partition liegt. Ich weiß nicht genau, wie im Kernel die Namensgebung der sd*-Devices erfolgt. Möglicherweise hängt (oder hing) sie davon ab, welche der beiden Disks zuerst hochläuft. Das würde zumindest erklären, dass nach einem Reboot (ohne Ausschalten des Rechners) die Namen meist wieder richtig waren. Schließlich ersetzte ich in der Boot-Konfiguration und in /etc/fstab die sd*-Namen durch die eindeutigeren UUIDs. Seither trat das Problem nicht wieder auf.
Yalu X. schrieb: > > Schließlich ersetzte ich in der Boot-Konfiguration und in /etc/fstab die > sd*-Namen durch die eindeutigeren UUIDs. Seither trat das Problem nicht > wieder auf. Dass die Device-Namen auch mal wechseln können ist ja eigentlich ein alter Hut, davor wird man überall gewarnt. Darf ich fragen welches System du benutzt? Hast du die fstab selber von der Pike auf geschrieben? Alle aktuellen Installer tragen da eigentlich direkt die UUID ein. Auch "genfstab" aus dem Arch-Umfeld macht das.
:
Bearbeitet durch User
Le X. schrieb: > Dass die Device-Namen auch mal wechseln können ist ja eigentlich ein > alter Hut, davor wird man überall gewarnt. Ich hatte bisher nie Probleme damit, deswegen war ich mir dessen nicht bewusst. > Darf ich fragen welches System du benutzt? Arch-Linux, aber es ist schon eine ältere Installation. > Hast du die fstab selber von der Pike auf geschrieben? Ich habe den Installer benutzt, der mir m.W. auch die Standardeinträge in fstab generiert hat. Aber wie gesagt, das ist schon eine ganze Weile her.
Yalu X. schrieb: > Ich hatte bisher nie Probleme damit, deswegen war ich mir dessen nicht > bewusst. Ich auch nicht, bin aber schon mehrmals über die Warnung gestolpert, möglichst keine device-Namen zu verwenden ;-) Yalu X. schrieb: > Ich habe den Installer benutzt, der mir m.W. auch die Standardeinträge > in fstab generiert hat. Aber wie gesagt, das ist schon eine ganze Weile > her. OK dann wurde das zwischenzeitlich geändert, genfstab trägt aktuell die UUID in die fstab ein.
Yalu X. schrieb: > Als ich die Sache aber näher > untersuchte, stellte ich fest, dass im Fehlerfall die Devicenamen der > beiden Disks (sda und sdb) vertauscht waren Guter Hinweis. Wenn der Fehler nochmal auftritt, achte ich darauf. Momentan werden bei mir die Linux und die Swap Partition per UUID eingebunden (das richtet der Installer so ein) aber die Medien-Parition als sdb3. Wenn sich die Device-Namen der Laufwerke ändern wäre das auch ein hundsgemeiner Fallstrick für Befehle wie: > cp debian_stick_image.iso /dev/sdc Ich habe mich bisher immer darauf verlassen, das sdc mein extern angesteckter Stick (bzw. die mobile Festplatte) ist.
Stefan ⛄ F. schrieb: > Yalu X. schrieb: >> Als ich die Sache aber näher >> untersuchte, stellte ich fest, dass im Fehlerfall die Devicenamen der >> beiden Disks (sda und sdb) vertauscht waren > > Guter Hinweis. Wenn der Fehler nochmal auftritt, achte ich darauf. In der Tat ein sehr interessanter Beitrag Yalus, aber deinen Fehlerfall kann das nicht abdecken: Stefan ⛄ F. schrieb: > Fehlermeldung war, dass meine > Medien-Partition auf der HDD nicht gemounted werden kann Es sein denn, du hast auf deiner HDD auch ein bootfähiges Linux installiert. Und selbst wenn dem so sein sollte (und Bios, +Grub/Lilo/whatever dir streiche spielten, der Teufel ist ein Eichhörnchen), dann wären die syslogs auf der "anderen" Platte.
@Yalu: Ich denke in deinem Fall wurden keinerlei syslogs auf irgendeine Platte geschrieben, du hast das Problem "live" debuggt. Sehe ich das richtig?
2aggressive schrieb: > Ich denke in deinem Fall wurden keinerlei syslogs auf irgendeine Platte > geschrieben, du hast das Problem "live" debuggt. Sehe ich das richtig? Als er beim booten gestoppt hat, konnte ich Ctrl-D drücken, um trotz des mount Fehlers fortzufahren. Von dem Zeitraum (8:12) habe ich Logmeldungen gefunden, aber darin keine relevanten Fehlermeldungen entdeckt. Das macht mich stutzig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.