diese Meldung bekomme ich z.Z.
Nach einer Weile ist der Rechner dann
komplett weg.
Zuerst hatte ich das Problem auf auf dem Desktop:
Leap 15.6 und einem Ryzen 5 3600.
Jetzt auch auf dem Laptop:
Tumbleweed und Ryzen 5 5500U.
Ich glaub nicht, dass beide Rechner zur gleichen Zeit kaputt gegangen sind.
Was kann ich tun?
Ich konnte das Problem eingrenzen.
Es ist
mount.cifs
Ich mounte Freigaben der Fritzbox und von anderen Rechnern in der Wohnung per bash-Script. Bevor die Fehlermeldungen kamen, kam eine Meldung, dass eine Freigabe nicht reagieren würde.
Ich habe das Script deaktiviert. Seitdem ist Ruhe.
Mounte ich die Freigaben, kommt sehr schnell der Fehler.
@Sauerland
Danke für die Nachfrage. Den Link kannte ich schon.
Evtl Firewall die dazwischen geht?
So handhabe ich das seit ewig. Warum sollte auf einmal die Firewall stören?
Das Problem habe ich erst seit heute.
Ich werde morgen die Firewall ausschalten und das Mounten testen.
Evtl liegt es ja auch an der Hardware der Freigabe…
Einen anderen Rechner mit Windows gestartet, die Freigabe gemountet.
Es dauerte keine Minute bis das Piepen anfing.
An der anderen Hardware liegt es nicht.
Für heute mache ich erstmal Schluß und zieh den Stecker vom Rechner.
Danke für die Unterstützung
Ich habe jetzt einiges durchgetestet.
Kontrahenten sind:
Rechner mit
Auf den Linux-Installationen gibt es die Freigaben via Samba.
Auf allen Installationen sind die Updates frisch.
Ergebnis:
Leap kollabiert bei Zugriff auf einen Windows-Rechner.
Alles andere funktioniert problemlos.
(das anfangs erwähnte Tumbleweed war falsch, ich hatte es durch Leap ersetzt)
Der Kollege hier hat scheinbar das gleiche Problem. Ich setze das nicht ein, würde aber vorschlagen, die Logs zu prüfen (dmesg / journalctl).
Ansonsten würde ich wie hier beschrieben mal versuchen, das Debugging zu aktivieren, evtl. liefert das einen Fingerzeig, wo man suchen muss.
Durch die Textwüsten von dmesg und journalctl hatte mich schon gequält und es jetzt noch mal getan. Das Debugging erzeugt dann noch mehr Text.
Hier mal dmesg bei Zugriff auf einen Samba-Server:
[ 1141.876191] CIFS: Attempting to mount //bonus/Daten
[ 1141.915143] CIFS: Attempting to mount //bonus/Toshiba
Und so bei Zugriff auf den selben Rechner mit Windows 11:
[ 413.074707] CIFS: Attempting to mount //bonus/Daten
[ 413.098896] CIFS: Attempting to mount //bonus/Toshiba
[ 413.100008] CIFS: VFS: BAD_NETWORK_NAME: \\bonus\Toshiba
[ 413.100017] CIFS: VFS: cifs_mount failed w/return code = -2
Und jetzt journalctl nach Einschalten des Debuggings:
[ 1090.149872] CIFS: Status code returned 0xc000019c STATUS_FS_DRIVER_REQUIRED
[ 1090.173198] CIFS: Status code returned 0xc000019c STATUS_FS_DRIVER_REQUIRED
[ 1090.174237] CIFS: Status code returned 0xc00000cc STATUS_BAD_NETWORK_NAME
[ 1090.174244] CIFS: VFS: BAD_NETWORK_NAME: \\bonus\Toshiba
[ 1090.174255] CIFS: VFS: cifs_mount failed w/return code = -2
[ 1131.350866] BUG: kernel NULL pointer dereference, address: 0000000000000098
[ 1131.350876] #PF: supervisor read access in kernel mode
[ 1131.350883] #PF: error_code(0x0000) - not-present page
[ 1131.350888] PGD 0 P4D 0
[ 1131.350894] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 1131.350900] CPU: 1 PID: 8656 Comm: python3 Tainted: G OE n 6.4.0-150600.23.7-default #1 SLE15-SP6 128952646fcb1614c051ed5f
88ec9aef64f90f32
Das ist nur der Anfang.
Danke für den Hinweis.
Du sagst ja, es hat bislang funktioniert. Wenn dann fast zeitgleich zwei Leute drüber stolpern, würde ich mal schwer vermuten, dass STATUS_BAD_NETWORK_NAME Unsinn ist und der Leap-Kernel ein Problem hat. Würde eigentlich empfehlen, auf der Mailingliste von linux-cifs nachzufragen, aber da SuSE wahrscheinlich den Kernel patcht, bin ich mir nicht sicher, ob die linux-cifs Leute was dazu sagen können. Insofern würde ich mal den nächsten Leap-Kernel abwarten, mit Tumbleweed funktioniert es ja.
Vielleicht passiert jetzt was:
https://bugzilla.opensuse.org/show_bug.cgi?id=1227194
Ich werde einen neuen Kernel abwarten.
Notfalls bleibt auch der Wechsel zu einer anderen Distribution.
Mit SLES 15 SP6 tritt der selbe Fehler auf.
Die watchdog Fehlermeldung kommt nach einem cifs-mount, wenn man SMB Protokoll-Version >= 3.0 verwendet, was Standard ist, wenn man die mont-Option “vers=” weglässt.
In der Folge ist das System unbenutzbar.
Bis “vers=2.1” funktioniert alles.
Für neuere Protokollversionen muss man die mount-Option “nohandlecache” verwenden.
Wir hoffen auf einen Fix und werden den Fehler dem SLES Support melden.
Danke für die Info.
Ich habe es getestet und es funktioniert. Super.
Für meinen Datensicherungsrechner kommt es aber zu spät. Der läuft jetzt mit Debian.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.