Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

niemand
15.12.2019 17:09:03

Auch der hier ursprünglich diskutierte Fehler trat ja jahrelang auf meinem System nicht auf.

… was aber halt eher Zufall war: dass sich die Laufwerkszuordnungen bei jedem Boot ändern können, ist seit Jahren zulässiges Verhalten. Daraus ’n Problem der neuen Kernel abzuleiten, halte ich daher für unzulässig.

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

niemand
29.11.2019 13:28:16

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.

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.

niemand
28.11.2019 19:11:54

Das bedeutet erstmal nur, dass die Meldung am besten 1:1 hier wiedergegeben werden sollte. Die Meldung, die kommt, wenn es kein passendes FS gibt, kann ebenso auf diese Weise interpretiert werden (sinngemäß: „kein oder ein defekter Superblock”) – deswegen: Copy&Paste der Meldung, idealerweise in code-Tags. Wäre das gleich am Anfang gekommen, wär’s Problem möglicherweise schon lange gelöst ….

Edit, um’s zu verdeutlichen:

% dd if=/dev/zero of=blub.img bs=1M count=50
50+0 Datensätze ein
50+0 Datensätze aus
52428800 bytes (52 MB, 50 MiB) copied, 0,0989785 s, 530 MB/s

% mkfs.vfat blub.img 
mkfs.fat 4.1 (2017-01-24)

% fsck.ext4 blub.img 
e2fsck 1.45.4 (23-Sep-2019)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext4: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
fsck.ext4: Ungültige magische Zahl im Superblock beim Versuch, blub.img zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>
[…]
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!

niemand
28.11.2019 13:42:51

Fünf verschiedene Laufwerke haben viel Potential, beim Booten mal umsortiert zu werden, ja. Wie geschrieben, kann ein Anpassen der Bootloaderconfig (und auch der fstab, wenn man schonmal dabei ist) solche Probleme beheben.

Ansonsten wäre der genaue Wortlaut der Meldungen für die Problemidentifizierung wichtig.

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.

niemand
27.11.2019 21:39:51

Ich hatte ’n ähnlich gelagertes Problem, bei dem die Ursache war, dass ich noch die alten, unzuverlässigen Laufwerksbezeichnungen in der Bootloaderconfig hatte. Dann hat’s alle paar Tage mal die Reihenfolge durcheinandergewürfelt, so dass es zum beschriebenen Fehler kam. Die Verwendung von UUIDs oder Labels in der Bootloaderconfig behebt das Problem, wenn es denn auch bei dir daran liegen sollte.

Fußzeile des Forums

Powered by FluxBB