[GELÖST] Systemabsturz nach Eject/Auswerfen von USB-Geräten

[ernstlx]

Hallo nochmals!

acpid.path und acpid.socket habe ich gestoppt, aber das hat nichts verbessert. Power-off führt zum Einfrieren des Systems.
Danke jedenfalls allen für die Tipps.

[willy4711]

Ich meine, dass es ein Bug in Thunar bzw. in udisksctl (udisks2) ist, was von Thunar nach dem umount aufgerufen wird.
Wie ich oben beschrieben habe, verhält sich Nemo unter Xfce vollkommen anders.
Auch das xfce4-mount-plugin verhält sich wie Nemo. Es wird in der Leiste plaziert.

Code: Alles auswählen

Nov 28 22:12:10 debianxfce udisksd[808]: Cleaning up mount point /media/willy/FILME (device 8:81 is not mounted)
Nov 28 22:12:10 debianxfce systemd[1]: Stopping Clean the /media/willy/FILME mount point...
Nov 28 22:12:10 debianxfce systemd[1]: Stopped Clean the /media/willy/FILME mount point.
Nov 28 22:12:10 debianxfce udisksd[808]: Unmounted /dev/sdf1 on behalf of uid 1000

Anscheinend führt der Aufruf von udisksctl (power off) zum Absturz des Systems. nemo und das xfce4-mount-plugin führen offensichtlich nur ein umount durch.
Wenn ich dann den Stick abziehe, schreibt das Journal

Code: Alles auswählen

kernel: usb 10-2: USB disconnect, device number 4

Nach thunar bzw udisksctl power off steht nichts mehr im Journal beim Abziehen
Mit thunar oder dem power off Befehl aus udisksctl wird der Stick elektrisch getrennt (ausgeworfen), was dann zum Absturz führt.

Eine Alternative, wären aus meiner Sicht dann Nemo bzw. das Xfce4-mount-plugin die man zumindest testen sollte.

[ernstlx]

Danke für die Empfehlung!

Das xfce-mount-plugin habe ich jetzt mal getestet. Wenn ich nicht explizit den absturzverursachenden Befehl hinzufüge (Benutzerdefinierte Befehle), hängt es bloß aus. Sehr komfortabel finde ich es nicht. Man kann zwar die Device-Namen ausblenden, aber nicht den Einhägepunkt. Bei oft recht langen UUIDs und deren Verwendung als Einhängepunkt führt das zu einer recht unübersichtlichen Anzeige.

Ich werde mal nemo testen. Mal sehen, ob ich mich daran gewöhnen könnte.

LG

[wileE]

Ich werde mal nemo testen.

Das kannst du dir sparen. Nemo und Nautilus sind auch betroffen.

Ich hoffe einfach das der nächste Kernel in dieser Hinsicht wieder funktioniert. Einen Fix für dieses Problem gibt es ja schon länger.

[ernstlx]

Danke für Info. Ich denke, ich kann für den Moment damit Leben, nicht "auszuwerfen".

[willy4711]

Das kannst du dir sparen. Nemo und Nautilus sind auch betroffen.

Ich wage das bei Nemo zu bezweifeln, da Nemo nicht mit udisksctl abschließt, sondern den Datenträger nur "umounted" (aushängt).
gnome-disks wirft den Datenträger wie Thunar ebenfalls aus (=udisksctl)

Die Frage, die sich mir hier abschließend stellt: Wo ist der Unterschied zwischen

Code: Alles auswählen

udisksctl power-off --block-device /dev/sdx

und

Code: Alles auswählen

Stecker ziehen

wenn das Device mit umount praktisch außer Betrieb ist

[wileE]

Ich wage das bei Nemo zu bezweifeln, da Nemo nicht mit udisksctl abschließt, sondern den Datenträger nur "umounted" (aushängt).

In Nemo Rechtsklick aufs Laufwerk, Option "sicher entfernen".

[ernstlx]

Um die Festplatte vom Strom zu trennen muss ich nicht einmal einen Stecker ziehen, nur einen Kippschalter an einer Steckerleiste umlegen, aber dazu muss ich zumindest aufstehen.

Aber es gibt Aussicht auf eine Verbesserung der Situation:
Ein Maintainer hat mir geschrieben (nach meinem bugreport), ich möge einen Backport-Kernel verwenden, bei dem das Problem bereits behoben ist. Ich weiß noch nicht, ob ich das machen werde, hoffe aber, dass auch ein stable-Kernel bald damit klarkommt.

[ernstlx]

Ich habe jetzt noch einige abschließende Tests gemacht:

Ich habe zuerst mein altes Betriebssystem (auf SATA-SSD) auf eine neue SATA-SSD (860 EVO) geklont. Kein Absturz durch Auswerfen (udisksctl power-off).
Dann habe ich mein neues Betriebssystem (auf M2-SSD) auf die selbe SSD geklont. Es kommt zum Absturz mit Kernel 4.9.0-8, nicht mit 4.9.0-7, genau wie mit der M2-SSD.

Was der Unterschied ist, kann ich nicht sagen (werde nicht mehr versuchen es herauszufinden), aber es ist definitiv nicht die Hardware und es tritt scheinbar nur bei Kernel 4.9.0-8 auf.

Was ich auch herausfinden konnte:
Mein altes Betriebssystem (SATA) bootet tatsächlich schneller (um rund 0,3s), aber nur, wenn es vom Bootloader der anderen SSD gestartet wird. Das ganze funktioniert auch umgekehrt.
Die Unterschiede in der Bootzeit der beiden Systeme auf der 860 EVO liegen innerhalb der Messunsicherheit.

[dirk11]

Wenn jemand "[Gelöst]" in den Titel schreibt, erwarte ich auch eine Lösung.

[cronoik]

Wenn jemand "[Gelöst]" in den Titel schreibt, erwarte ich auch eine Lösung.

Nimm nicht den Kernel 4.9.0-8 ist die Loesung.

[dirk11]

Das ist keine Lösung, sondern ein Umschiffen des Problem.

[ernstlx]

Hallo dirk11,
nachdem es sich um einen Kernel bug handelt, ist im Moment wohl nicht mehr als ein Workaround, also ein Umschiffen, drinnen. Es hat für mich keinen Sinn herauszufinden, unter welcher abweichenden Konfiguration das Problem nicht auftritt. Ich bin mit meiner derzeitigen Konfiguration recht glücklich und habe stattdessen begonnen, andere Bugs und Fehlkonfigurationen, von denen es nach der Neuinstallation einige gegeben hat, zu beseitigen:

-- So war zum Beispiel der NetworkManager aktiv und gleichzeitig war /etc/network/interfaces konfiguriert. In interfaces.d/setup stand zunächst der falsche, veraltete Netzwerkadapter eth0, was nicht nur zu einer Fehlermeldung im journal geführt hat, sondern auch die Bootzeit geringfügig verlängert. Korrekt heißt mein Netzwerkadapter jetzt enp0s31f6, aber auch der sollte nicht in interfaces.d/setup eingetragen werden, da sonst zwei mal eine DHCP-Abfrage stattfindet (was die Bootzeit deutlich verlängert). interfaces.d/setup sollte gar nicht konfiguriert sein, da diese Funktion NetworkManager übernommen hat.
-- nfs-blkmap.service erzeugte eine Fehlermeldung. Da ich pNFS nicht benötige, habe ich es eliminiert (systemctl mask). (ich betreibe einen NFS-Server nur für meine Kodi-Mediastation)
-- nfsdcltrack "Failed to init database". Ich weiß nicht, ob ich das benötige, aber ich habe die gesuchte sqlite-Datenbank angelegt (nfsdcltrack init https://bugs.debian.org/cgi-bin/bugrepo ... bug=867067).
-- avahi-daemon startete zu früh (hab ich im service-File editiert --> After=network-online.target).
Ich habe jetzt keine Fehlermeldungen mehr*, mein System bootet in 6,2s und ich kann mich beherrschen, in nächster Zeit nicht auf "Auswerfen" zu klicken. Für mich ist das Problem gelöst.

*) naja, außer die ACPI-Fehler, die ich zu Beginn des Beitrags vorgebracht habe und die auch schon bei meinem alten System auftraten ...

[edit]
Die Aussagen zum NetworkManager stimmen nur bedingt (siehe: https://wiki.debian.org/NetworkManager), aber nach der Installation war das trotzdem eine Fehlkonfiguration!

[ocram]

Wie machst du das Aushängen in Thunar?
Klick auf das Pfeil Symbol? Mach doch mal einen Rechtsklick auf das Laufwerk und dann "Aushängen" und "Auswerfen".

Wenn der Absturz bei Auswerfen passiert hast du auch das power-off Problem.
Wie hier: viewtopic.php?f=13&t=171367
Und wie bei mir.

Gleiches Problem hier. Externe USB 3.0 Festplatte am USB 3.0 Port mit kernel 4.9.0-8-rt-amd64. Ich habe ausgehängt, was problemlos ging und dann ausgeworfen, worauf das System einfror. Nach einem Neuboot wird mir nun aber die Option Auswerfen gar nicht mehr gegeben, da ausgegraut. Reicht es nicht einach den Stecker zu ziehen oder ist ein Auswerfen wirklich von Nöten?

Nochmal getestet: Platte über den Powerbutton in der Laufwerksverwaltung (gnome-disk-utility) ausgeschaltet -> System Freeze

Mit kernel 4.9.0-7 tritt das Problem nicht auf!

[ernstlx]

Hallo ocram!

Reicht es nicht einach den Stecker zu ziehen oder ist ein Auswerfen wirklich von Nöten?

"Auswerfen" ist nicht erforderlich. Wenn das Gerät ausgehängt ist, kann man gefahrlos den Stecker ziehen.

Mit kernel 4.9.0-7 tritt das Problem nicht auf!

Das Problem tritt auch mit neueren Kernelversionen nicht auf (4.17 oder 4.18 aus debian-backports). Ich persönlich verwende aber weiterhin 4.9.0-8 und vermeide "Auswerfen".
Liebe Grüße

[ocram]

Hallo ocram!

Reicht es nicht einach den Stecker zu ziehen oder ist ein Auswerfen wirklich von Nöten?

"Auswerfen" ist nicht erforderlich. Wenn das Gerät ausgehängt ist, kann man gefahrlos den Stecker ziehen.

Mit kernel 4.9.0-7 tritt das Problem nicht auf!

Das Problem tritt auch mit neueren Kernelversionen nicht auf (4.17 oder 4.18 aus debian-backports). Ich persönlich verwende aber weiterhin 4.9.0-8 und vermeide "Auswerfen".
Liebe Grüße

Danke, ich werde es dann auch so handhaben. Zumal mein Gehäuse ja sogar noch einen Schalter hat ...

[peter1969]

Übrigens: bei mir tritt das Problem auch mit einem USB-Stick (USB 3.0, 32G) auf. Bei einem kleineren USB-Stick der gleichen Marke (USB3.0, 16G) jedoch nicht.