Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Takeshi Kovacs
15.12.2019 12:23:54

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.

Takeshi Kovacs
01.12.2019 11:24:16

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
30.11.2019 11:27:54

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 smile, bis ich im amerikanischen Arch-Forum den Hinweis darauf fand, unter Windows sämtliche Energiespar-Modi für die Karte abzuschalten.

jessie
30.11.2019 11:22:02

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
29.11.2019 19:55:01

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!

Takeshi Kovacs
29.11.2019 19:31:45
niemand schrieb:

Ich 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 smile 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
29.11.2019 10:39:41

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.

hollex
28.11.2019 14:17:21
Takeshi Kovacs schrieb:

Die „Notfallkonsole“ verweigert das Ausführen des fsck-Befehls mit einer Meldung über einen defekten Super-Block.

Das deutet aber eher auf ein anderes Problem hin!

Takeshi Kovacs
28.11.2019 11:16:15

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

Hackepeter
28.11.2019 07:52:25

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
27.11.2019 21:15:07

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.

hollex
27.11.2019 13:48:05

Ich würde Windows10 komplett deinstallieren und die Partition gleich neu formatieren mit z.B. ext4.
==> dann läuft das System und Du hast Ruhe (war bei mir auch mal so) !
https://askubuntu.com/questions/849872/ … every-time

Alternativ könntest Du auch vor jedem Booten von Win10, die Arch-SSD physisch vorher abklemmen! smile
Weitere Alternative: ==> Win10 in eine VM installieren. Ist zwar nicht unmöglich, wird aber für das "Fenster10"
weitaus schwieriger von dort aus Ärger zu machen.

stefanhusmann
27.11.2019 12:25:57

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
26.11.2019 22:23:41

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?

Fußzeile des Forums

Powered by FluxBB