TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Moin @ all Beim experimentieren mit dem neu installierten Grafiktreiber hatte ich in der Bootphase auf einmal einen merkwürdigen Effekt. Kurzzeitig wird der lila-farbene Bootbildschirm auf (ich vermute) VGA-Auflösung runtergesetzt und dann mit riesigen Buchstaben mit Fehlermeldungen vollgeschrieben. Ich konnte in den wenigen Sekunden genügend lesen, um diese Fehlermeldung zu erkennen. Ich habe dann mal in die Syslog reingeschaut und die passenden Meldungen gefunden: Aug 30 19:57:27 ThomasPC kernel: [ 16.446584] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.447002] CIFS VFS: cifs_mount failed w/return code = -101
Aug 30 19:57:27 ThomasPC kernel: [ 16.449328] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.450443] CIFS VFS: cifs_mount failed w/return code = -101
Aug 30 19:57:27 ThomasPC kernel: [ 16.460704] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.461065] CIFS VFS: cifs_mount failed w/return code = -101
Aug 30 19:57:27 ThomasPC kernel: [ 16.463625] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.463729] CIFS VFS: cifs_mount failed w/return code = -101
Aug 30 19:57:27 ThomasPC kernel: [ 16.464601] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.465034] CIFS VFS: cifs_mount failed w/return code = -101
Aug 30 19:57:27 ThomasPC kernel: [ 16.468217] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.468518] CIFS VFS: cifs_mount failed w/return code = -101
Aug 30 19:57:27 ThomasPC kernel: [ 16.475077] CIFS VFS: Error connecting to socket. Aborting operation.
Aug 30 19:57:27 ThomasPC kernel: [ 16.476195] CIFS VFS: cifs_mount failed w/return code = -101 Ich hatte erst gedacht, das hängt mit meiner NVidia-fummelei zusammen, weil ich das vorher noch nie gesehen habe. Hat aber nix damit zu tun, denn die Meldungen finde ich im Log bei jedem Boot.... nur wurden die vorher mit Nouveau als Treiber nie angezeigt. Interessant ist, dass alles funktioniert.... es gibt keine Probleme bei den Mounts. Aber anscheinend bestehen doch irgendwo Probleme. Hat jemand ne Idee, wo das herkommen könnte? Oder noch besser, wie man das beseitigen kann? Gruß Thomas
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Vermutlich versucht Dein System, die cifs-Freigabe bereits zu mounten, bevor die Verbindung zum Netzwerk steht. Irgend wann klappt es dann ... Versuche mal, in dem fstab-Eintrag für die cifs-Freigabe noch die Mount-Option _netdev einzufügen (mit dem underscore) und berichte, wie dieses sich auswirkt. Gruß – Max-Ulrich
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Moin Max-Ulrich Farber schrieb: Vermutlich versucht Dein System, die cifs-Freigabe bereits zu mounten, bevor die Verbindung zum Netzwerk steht. Irgend wann klappt es dann ...
Versuche mal, in dem fstab-Eintrag für die cifs-Freigabe noch die Mount-Option _netdev einzufügen (mit dem underscore) und berichte, wie dieses sich auswirkt.
Leider hat das nichts bewirkt. Aber ich habe mal gegengeprüft und die fstab-Einträge auskommentiert. Ergebnis: Keine Fehlermeldungen. Also ist tatsächlich die fstab Verursacher der Fehlermeldungen durch (vermutlich) einen zu frühen mount.... denn wenn der Rechner hochgefahren ist, gibts keine Fehler mehr, da alle mounts erfolgreich waren. Im Grundegenommen wird man das ignorieren können, aber es ist total unschön und verschleiert vielleicht andere Fehlermeldungen, die untergehen. Gibt es vielleicht ne andere Lösung, diese Fehlermeldungen zu beseitigen? Das sind die die Fehlermeldungen "verursachenden" Mounts:
//1.1.1.2/HD_1 /media/HD_1 cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 1
//1.1.1.2/HD_2 /media/HD_2 cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 0
//1.1.1.2/Home_Thomas /media/Home_Thomas cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 0
//1.1.1.2/DatenAlle /media/DatenAlle cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 0
//1.1.1.2/Mail /media/Mail cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 0
//1.1.1.2/MultiMedia /media/MultiMedia cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 0 Gruß
Thomas
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Leider hat das nichts bewirkt
Das wundert mich etwas. Denn wenn es an der noch nicht stehenden Netzwerk-Verbindung liegt, dann sollte _netdev das Problem beseitigen. Ich würde doch noch versuchen, die Option _netdev weiter nach vorne zu ziehen, obwohl ich selbst bezweifle, dass dies wirklich einen Wert hat. //1.1.1.2/HD_1 /media/HD_1 cifs credentials=/home/thomas/.smbcredentials,auto,rw,suid,dev,exec,async,_netdev 0 1
Noch ein paar Fragen: Wozu brauchst Du die markierten Optionen? Außer suid,dev,exec sind sie sowieso Standard, und wozu die anderen bei einer cifs-Freigabe gebraucht werden, sehe ich nicht. Außerdem würde ich am Schluss 0 statt 1 setzen, denn eine cifs-Freigabe kann ja nicht beim Start automatisch überprüft werden. Sollte alles Andere nichts nützen, kann man immer noch mit der Mount-Option nofail die lästigen Fehlermeldungen unterdrücken. Aber schöner ist es schon, den Fehler selbst zu verhindern. Gruß – Max-Ulrich
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Hallo Max-Ulrich Farber schrieb: > Sollte alles Andere nichts nützen, kann man immer noch mit der Mount-Option nofail die lästigen Fehlermeldungen unterdrücken. Aber schöner ist es schon, den Fehler selbst zu verhindern.
Ich habe jetzt einige Zeit expemimentiert... Parameter rein und raus... ohne Effekt... die Fehlerliste rasselt am Anfang weiterhin runter. Und besonders erfreulich... 😕 ... sie rasselt auch bei nofail runter. Eigentlich haben _netdev und nofail überhaupt keine Auswirkung. Was vielleicht bemerkenswert ist.... ?vielleicht?... ist die Liste der "angenommenen" Parameter:
/dev/sda1 on /media/Lokal_C_System type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=4096)
/dev/sda2 on /media/Lokal_D_Daten type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=4096)
//1.1.1.2/Home_Thomas on /media/Home_Thomas type cifs (rw)
//1.1.1.2/Mail on /media/Mail type cifs (rw)
//1.1.1.2/DatenAlle on /media/DatenAlle type cifs (rw)
//1.1.1.2/HD_2 on /media/HD_2 type cifs (rw)
//1.1.1.2/HD_1 on /media/HD_1 type cifs (rw) Bei allen Mounts stehen die entsprechenden Parameter dahinter. Nur bei "meinen" nicht, es wird anscheinend nur rw angenommen. Kann es sein, dass der Server da noch die Hand im Spiel hat, welche Client-Parameter er beim Mounten erlaubt? Gruß, Thomas
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Kann es sein, dass der Server da noch die Hand im Spiel hat, welche Client-Parameter er beim Mounten erlaubt?
Indirekt schon. Wenn die Freigabe dort z.B. nicht schreibberechtigt ist, dann ist rw wirkungslos. Aber das siehst Du bei mount auf dem Client nicht. Hier ist etwas Anderes der Fall: Die Routine mount bindet cifs-Freigaben nicht selbst ein, sondern sie verwendet dafür die Hilfsroutine ("helper program") mount.cifs . Und diese unterstützt nicht alle Mount-Parameter. Dafür kennt sie aber auch ein paar eigene Parameter, die mount sonst nicht kennt. – Vielleicht ist das auch der Grund, warum die Optionen _netdev und nofail offenbar ignoriert werden. Doch dies würde mich wundern. Wenn ich morgen Zeit habe, will ich da mal selbst etwas herumprobieren. Gruß – Max-Ulrich P.S.: Ich habe da etwas gesucht. Tatsächlich gibt es eine Fehlermeldung für cifs-utils von 2012, dass mount.cifs die Option _netdev ignoriert! Welche Samba-Version läuft denn bei Dir, und auf welcher Ubuntu-Version baut XBMCbuntu auf?
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Max-Ulrich Farber schrieb: Kann es sein, dass der Server da noch die Hand im Spiel hat, welche Client-Parameter er beim Mounten erlaubt?
Indirekt schon. Wenn die Freigabe dort z.B. nicht schreibberechtigt ist, dann ist rw wirkungslos. Aber das siehst Du bei mount auf dem Client nicht. Hier ist etwas Anderes der Fall: Die Routine mount bindet cifs-Freigaben nicht selbst ein, sondern sie verwendet dafür die Hilfsroutine ("helper program") mount.cifs . Und diese unterstützt nicht alle Mount-Parameter. Dafür kennt sie aber auch ein paar eigene Parameter, die mount sonst nicht kennt. – Vielleicht ist das auch der Grund, warum die Optionen _netdev und nofail offenbar ignoriert werden. Doch dies würde mich wundern. Wenn ich morgen Zeit habe, will ich da mal selbst etwas herumprobieren. Ich habe da etwas gesucht. Tatsächlich gibt es eine Fehlermeldung für cifs-utils von 2012, dass mount.cifs die Option _netdev ignoriert! Welche Samba-Version läuft denn bei Dir, und auf welcher Ubuntu-Version baut XBMCbuntu auf?
Der Server ist ja konzeptionell bei mir zuhause als File-Server gedacht. Ausserdem ist er noch Print-Server und OpenVPN-Server. Aber er ist kein Streaming-Server, auch kein MultiMedia-Server. Das heisst, alle User haben natürlich auf die bzw. ihre relevanten Verzeichnisse die Schreibrechte. Das funktioniert ja soweit auch. Zumal auf den Windows-Clients überhaupt nix mit Fehlermeldungen passiert. Das läuft ganz sauber durch. Ich glaube auch fast nicht, dass da die Ursache der Probleme liegt. Die User kommen an die gemeinsamen Freigaben dran, und jeder nur persönlich an seine eigenen Freigaben. Als Clients werkeln da unterschiedliche Systeme, mehrere Windows 7 prof, Ubuntu 14.04 LTS, verschiedene Android-Clients. Die Fehlermeldungen sehe ich nur auf meinem Kubuntu-Client. Jetzt habe ich mal wegen der Versionen nachgesehen. Bei XMBC musste ich erst mal googlen, was das überhaupt ist. Das ist bei mir weder auf dem Server noch auf dem Ubuntu-Client installiert... wie gesagt, funktional ist der Server eher ein reiner Office-Server. Der Server ist ein Raspberry Pi mit Raspian Wheezy
Raspbian GNU/Linux 7
Linux version 3.12.26+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #707 PREEMPT Sat Aug 30 17:39:19 BST 2014
Samba ist die Version 3.6.6 Mein KUbuntu-Client ist ein Trusty Tahr 14.04 LTS Bis vor ein paar Wochen lief über mehrere Jahre (7/24) bei mir ein Windows-Server... mit immer über 100W Stromaufnahme. Ich habe das jetzt "umgebaut" auf einen Linux-Server, und zwar den Raspberry PI. Der Stromverbrauch mit 2 großen Platten liegt heute bei 8 Watt. Und der "kleine" erfüllt zu 100% alle unsere Anforderungen... und das sogar richtig gut. Nur eben jetzt diese merkwürdigen Randeffekte.... HTH Gruß, Thomas
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
Die Kernel- und Samba-Versionen sind, soweit ich sehen kann, aktuell von 2014. Es handelt sich um Samba-3, das ist evtl. mal wichtig zu wissen. Ich habe jetzt etwas den Überblick verloren. Welche Probleme sind jetzt bei Dir noch offen bzw. was läuft noch nicht genau so wie gewünscht? Wenn es nur noch die lästigen Fehlermeldungen sind (?), dann gibt es noch den Weg, die fstab-Einträge durch entsprechende Einträge in /etc/rc.local, aber mit anderer Syntax, zu ersetzen. Dort kann man dann das Mounten etwas verzögern, sodass die Netzwerk-Verbindung sicher schon steht. fstab muss ja nicht sein, wenn keine automatische Überprüfung der Partitionen nötig bzw. möglich ist, und nichts mehr nachfolgt, was die gemounteten Freigaben benötigen würde.. Gruß – Max-Ulrich
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Hallo Es geht immer noch um die auf dem Boot-Bildschirm in riesigen Buchstaben erscheinenden Fehlermeldungen .... verursacht durch die fstab. Und das _nodef und nofail keine Auswirkungen zur Behebung dieses Problems haben.
Ich habe jetzt mal Deine Idee verfolgt und die Mounts in die rc.local eingetragen. Ich hatte selber sogar heute morgen mal die Idee, mich mit einem kleinen Script in die RUN-Levels einzuhängen, aber rc.local ist ja eine viel bessere Lösung. Nun ja, die Fehlermeldungen in der Bootphase sind damit beseitigt. Wobei ich nicht so recht einschätzen kann, ob das jetzt ein eher unkonventioneller Lösungsweg ist, der halt funktioniert, oder ob das zudem auch "Regelkonform" ist.... weil, nicht alles, was funktioniert, ist ja immer regelkonform. Und manchmal wird man ja irgendwann mal auch fürs "Abseits der Piste zu fahren" bestraft. So sieht jetzt die rc.local aus.... meine mounts habe ich vorher in der fstab entfernt und sie dann hier hinter den (schon vorher vorhandenen) ersten zwei Zeilen der rc.local gesetzt:
sleep 20
mount -a
mount -t cifs -o credentials=/home/thomas/.smbcredentials,defaults //1.1.1.2/HD_1 /media/HD_1
mount -t cifs -o credentials=/home/thomas/.smbcredentials,defaults //1.1.1.2/HD_2 /media/HD_2
mount -t cifs -o credentials=/home/thomas/.smbcredentials,defaults //1.1.1.2/Home_Thomas /media/Home_Thomas
mount -t cifs -o credentials=/home/thomas/.smbcredentials,defaults //1.1.1.2/DatenAlle /media/DatenAlle
mount -t cifs -o credentials=/home/thomas/.smbcredentials,defaults //1.1.1.2/Mail /media/Mail
mount -t cifs -o credentials=/home/thomas/.smbcredentials,defaults //1.1.1.2/MultiMedia /media/MultiMedia Ergebnis: Keine Fehlermeldungen mehr in der Bootphase. Interessant ist, dass hier noatime zu Fehlermeldungen führt, weswegen ich diesen Parm hier entfernt habe.Eigentlich fand ich die Bedeutung von noatime gut, schade, dass das so nicht nutzbar ist. Gruß, Thomas
|
Max-Ulrich_Farber
Anmeldungsdatum: 23. Januar 2007
Beiträge: 7992
|
weil, nicht alles, was funktioniert, ist ja immer regelkonform
Eine Regel gibt es da eigentlich nicht. Es war früher mal die Rede davon gewesen, wegen udev die Datei rc.local zu ersetzen, aber davon redet anscheinend keiner mehr. Damit ist das Verfahren IMO absolut korrekt. Die fstab bietet halt noch ein paar zusätzliche Möglichkeiten (z.B. das Überprüfen von Partitionen), die Du in diesem Fall aber gar nicht brauchst. Du musst Dir halt merken bzw. notieren, wo Du die Einträge vorgenommen hast, falls Du mal was ändern willst. 😉 Dass die Option noatime nicht funktioniert liegt sicher an Samba bzw. cifs . Bei der fstab werden wohl die Mount-Optionen, die nicht gehen, stillschweigend ausgefiltert, weil man dort Fehlermeldungen so schlecht unterdrücken kann. Das ist bei rc.local nicht der Fall. Aber die Zeile mount -a brauchst Du dann nicht mehr, da ja keine noch offenen fstab-Einträge mehr da sind. Und das sleep 20 ist eventuell auch überflüssig bzw. unnötig lang.
|
TomLu
(Themenstarter)
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Hallo Zunächst mal das wichtigste vorab... ein herzliches Danke für Deine Hilfe... soviel Zeit zu "verschwenden" kann man nicht einfach so erwarten... selbstverständlich ist das jedenfalls nicht... also: 👍 Max-Ulrich Farber schrieb: Aber die Zeile mount -a brauchst Du dann nicht mehr, da ja keine noch offenen fstab-Einträge mehr da sind. Und das sleep 20 ist eventuell auch überflüssig bzw. unnötig lang.
Ja... "mount -a" ...?... da gibts aber in der fstab noch 2 Einträge, die definitiv nicht von mir sind und die -ich vermute- beim Setup maschinell erstellt wurden. Wurde die fstab in der Vergangenheit bei jedem Systemstart 2 mal "abgearbeitet"? Einmal irgendwie vom Kernel oder einem Job in den Runlevels und dann noch einmal über rc.local? Wenn ja, dann könnte der Eintrag ja wirklich raus. Aber die 20 Sekunden lass ich erst mal. Ich habs vorhin mal getestet, ich hatte sofort mit dem nach dem Boot verfügbaren Desktop Dolphin gestartet und die Freigaben gecheckt... und sie waren alle da. Also passt das doch alles bestens. Apropos merken. Ich habe mir schon vor Tagen ein Script gebastelt, welches mir einmal wöchentlich ein Backup mit ganz gezielten Files in ein Tar.GZ-Archiv packt... da kann ich das nicht vergessen. Das ist beispielsweise die Liste in meinem @IncludeFile
/etc/samba/smb.conf
/etc/fstab
/etc/cups/cupsd.conf
/etc/cups/printers.conf
/etc/default/openvpn
/etc/openvpn
/etc/ntp.conf
/etc/hdparm.conf
/etc/crontab
/etc/sysctl.conf
/etc/rc.local
/media/Home_Thomas/Linux
/usr/local/bin
/home/thomas/Schreibtisch Bis denne mal... beim nächsten Problem ☺ Thomas
|