Takeshi Kovacs
Hallo zusammen,
seit einigen Wochen zeigt mein Arch Linux nach dem Starten immer mal wieder an, dass es kein bekanntes Dateisystem für das Laden der root-Partition (ext4) entdecken könne. Die „Notfallkonsole“ verweigert das Ausführen des fsck-Befehls mit einer Meldung über einen defekten Super-Block. Die dort vorgeschlagenen alternativen fsck-Befehle werden auch nicht ausgeführt.
Nach einem Warm-Start fährt Linux ganz normal ohne jede Fehlermeldung hoch. Die eingesetzten SSD-Festplatten sind vollkommen ok - vom parallel installierten W10 aus getestet.
Nach einigen Tagen taucht der Fehler dann mal wieder auf.
Hat jemand von Euch eine Idee wie ich das Ganze in den Griff bekommen kann?
stefanhusmann
Ich würde von einem externen Medium aus booten (USB-Stick, CD oder dergl.) und dort mitteld fsck versuchen den Superblock zu reparieren. Wenn das auch nicht hilft, könnte die SSD kaputt sein. Mit W10 kenne ich mich nicht aus, aber ich würde Microsoft nicht trauen, wenn es um Hardwarediagnose geht.
Takeshi Kovacs
Vielen Dank für Eure Infos. Verstehe ich das richtig, dass dies möglicherweise ein dauerhaft von Windows 10 verursachter Fehler sein könnte? Und würde die Reparatur von einem externen Datenträger dann nicht ins Leere laufen? Wobei mein Linux beim 2. Bootversuch nach Warmstart ja wieder problemlos startet.
Hackepeter
Schau mal bitte nach der genauen Fehlermeldung. Ich habe ein ähnliches Problem. Ich glaube, vorher kommt
kernel: ata1.00: failed to set xfermode (err_mask=0x40)
Dann einfach neustart und es geht. Eine Lösung habe ich dafür noch nicht.
Takeshi Kovacs
Dies ist meine fstab Datei - sollte ich hier etwas umstellen - der Bootvorgang hängt, da er die Partition /dev/sdc1 nicht identifizieren kann - die genauen Meldungen müsste ich mal mitprotokollieren - da sie mir nicht gegenwärtig sind.
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sdc1 UUID=46c00db9-b80b-4fc1-8963-bf8bf3426237
LABEL=arch / ext4 rw,relatime,data=ordered 0 1
# /dev/sdb2 UUID=92EE-C4FC
/dev/sdb2 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
# /dev/sdc2 UUID=5837aa3a-03a0-437b-8758-0d6cb5c59508
LABEL=swap none swap defaults 0 0
/dev/sda1 /mnt/Seagate ntfs-3g uid=uwe,gid=users,noauto,x-systemd.automount 0 0
/dev/sdd2 /mnt/ironwolf ntfs-3g uid=uwe,gid=users,noauto,x-systemd.automount 0 0
/dev/sde1 /mnt/westerndigital ntfs-3g uid=uwe,gid=users,nofail,noauto,x-systemd.automount,x-systemd.device-timeout=20 0 0
/dev/sdc3 /mnt/pro850 ntfs-3g uid=uwe,gid=users 0 0
Takeshi Kovacs
Ja, ich werde beim nächsten Fehler mal den Bildschirm abfotografieren.
Ich hatte meine fstab komplett auf die Zuordnung "UUID=..." umgestellt. Danach ist der Fehler allerdings gestern einmal wieder aufgetaucht. Tatsächlich tritt der Fehler sehr selten auf, wenn ich zuvor Win10 gebootet hatte; meistens eher, wenn ich direkt nach Einschalten des PCs Arch boote oder Linux ein zweites Mal starte.
Takeshi Kovacs
niemand schriebIch hatte meine fstab komplett auf die Zuordnung "UUID=..." umgestellt. Danach ist der Fehler allerdings gestern einmal wieder aufgetaucht.
Deswegen schrieb ich, dass es eine gute Idee wäre, das auch in der Bootloaderkonfiguration anzupassen. Die fstab ist erst von Bedeutung, wenn das System überhaupt soweit durchbootet, um darauf zugreifen zu können.
Oh, das hatte ich missverstanden - an meinem Bootloader war ich seit Jahren nicht mehr "dran" - habe ihn auch nur mühsam gefunden 🙂 Er sieht jetzt so aus:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=/dev/sdc1 rw
Da kann mann jetzt auch die UUID - Bezeichnung eintragen - also so?
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=46c00db9-b80b-4fc1-8963-bf8bf3426237 rw
Takeshi Kovacs
Noch ein Nachtrag - ich habe das jetzt einfach mal so getestet und immerhin ist mein Arch noch gestartet.🙂 Bei näherer Betrachtung ist die Theorie mit dem Bootloader recht erfolgversprechend. Denn wenn wirklich der "Superblock" der Partition beschädigt wäre, dürfte das System nach Warmstart ja nicht jedes Mal wieder problemlos booten.
Jetzt muss das System natürlich ein paar weitere Boot-Versuche "überleben", um beurteilen zu können, ob das Ganze jetzt gelöst ist. Ich werde bald berichten - noch einmal vielen Dank für Eure Beiträge!
jessie
Ich habe ebenfalls ein ähnlich gelagertes Problem. Aber ich gehe dem nicht weiter nach, da ich beobachtet habe, dass dieses erstmals mit Kernel 5.3 auftrat. Vorher definitiv nicht. Daher, und da 5.4 bereits in den Startlöchern steht, warte ich erstmal noch ab. Zumal ich alle anderen Lösungsansätze für wenig zielführend halte, bei einem Problem, dass nur gelegentlich auftritt...
Schönen 1. Advent euch allen!
Takeshi Kovacs
Ja, das könnte auch bei mir so gewesen sein. Jahrelang traten solche Probleme niemals auf. Erst seit eine der neuen Kernel-Versionen installiert ist....
Das einzige Problem vorher mit Win10 Dual-Boot war die Ansteuerung der Onboard Intel-Netzwerkkarte von dort. Linux konnte danach die Netzwerkkarte nicht mehr korrekt ansprechen. Dies hatte mich damals fast verrückt gemacht 🙂, bis ich im amerikanischen Arch-Forum den Hinweis darauf fand, unter Windows sämtliche Energiespar-Modi für die Karte abzuschalten.
Takeshi Kovacs
Hallo zusammen - ein Zwischen-Fazit möchte ich schon abgeben.
Nach der von "niemand" vorgeschlagenen Änderung des Boot-Loaders auf UUID Angabe für die root-Partition (options root=UUID=46c00db9-b80b-4fc1-8963-bf8bf3426237 rw) trat der Fehler bisher nicht einmal mehr auf. Allerdings werde ich das Ganze noch ein paar Tage beobachten müssen,
Takeshi Kovacs
Der Fehler scheint wohl wirklich endgültig gelöst zu sein. Dafür bootete Arch gestern nach einem vollständigen Update, dass den Kernel nicht betraf, gar nicht mehr. Fehlermeldung deutete auf ein Problem mit der per USB angeschlossenen externen Festplatte hin (irgendetwas mit Cache). Auskommentieren in der Fstab der Harddisk half auch nicht. Erst nachdem ich per True-Image die Linuxpartition zurückgesetzt hatte, startete das System wieder problemlos. Ein erneutes Update brachte dann den ganz neuen Kernel mit und damit funktioniert jetzt auch alles wieder nach dem Update.
Irgendwie beschleicht mich langsam der Gedanke, dass die neuen Kernel doch einige Probleme bei der Ansteuerung von Festplatten mitbringen. Auch der hier ursprünglich diskutierte Fehler trat ja jahrelang auf meinem System nicht auf.