Hallo Thomas,
das kann ich bestätigten! Es ist deutlich spürbar, dass es flotter läuft!
Beim Durchlauf von linuxmuster-import-devices habe ich allerdings eine (neue?) Meldung, die ich mir nicht erklären kann: Ich bekomme für die VM, die als Master dient, zwei Mal das hier:
ERROR in Sophomorix::SophomorixSambaAD::AD_computer_create:
0000202F: samldb: spn[HOST/SERVER] would cause a conflict
* serverraum must be created RUNTIME
In der devices.csv gibt es aber nur einen Eintrag für diese Maschine. Hängt das evtl mit den Beobachtungen von @thoschi zusammen, dass da irgendwo Reste im AD stehen bleiben??
Hast Du eine Idee?
per SSH auf dem Surface nachgeschaut - da stimmte die start.conf nicht überein. Also nochmal alles platt gemacht und neu synchronisiert.
Und tatsächlich geht es jetzt - an was auch immer es lag (Linbo-Version hatte ich eigentlich überprüft).
Noch etwas erfreuliches:
Nach https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup vorgegangen und auf dem Server den Surface-Kernel installiert und als Linbo-Kernel eingestellt. Et voila: Linbo kann nun auch auf Surface-Geräten per Touch bedient werden.
Hallo Thomas,
„Scotty wir haben ein Problem“…
Gestern habe ich das linbo-update auf 4.2.11 eingespielt und heute starten meine PCs nicht mehr.
Am PC folgendes ausgegeben - läuft noch unter 4.2.10 (auch bei boot per usb-stick mit linbo 4.2.11:
Interface etho: got 10.24.28.2.
/init.sh: /env: line 33: syntax error: unterminated quoted string
Not splitting minimal start.comf.
/inbo.sh: /env: line 33: syntax error: unterminated quoted string
kann ich im Moment nicht nachvollziehen. Hier läuft das produktiv ohne Probleme. Gehe auf 4.2.10 zurück, ggf. mit der forced netboot Methode. Und schau mal, was auf dem Linboclient in /.env drinsteht.
Hallo Thomas,
danke für die schnelle Rückmeldung - es lag an mir…
Wir haben unsere sophos gegen eine opnsense ausgetauscht, dabei hat sich das default-gateway und der dns-forwarder geändert. Beim Anpassen habe ich wohl etwas (was ich leider nicht weiß was…) kaputt gemacht… - wahrscheinlich die Namensauflösung.
Jetzt geht es aber wieder.
Danke!
Tach,
4.2.11 crasht bei uns 50% der Rechner mit aelterer Hardware das Image beim Einspielen, „trace“-Meldungen verheissen nix Gutes. Keine Ahnung wieso, das muss beim Umkopieren aus dem Cache passieren.
Vermute da vertraegt sich Linbokernel 6.6.4 irgendwie nicht mit dem alten Mainboard?
Back to 4.2.10 und das tut wieder, zumindest testen wir das gerade. Ich werde erstmal keine Upgrades von Linbo mehr machen, es sei denn es gibt den postsync-Parameter bei linbo-remote
vertraegt sich Linbokernel 6.6.4 irgendwie nicht mit dem alten
Mainboard?
… dann würde es ja eher bei allen crashen.
Ich habe inzwischen auch ab und an ein „crash“.
Meine Rechner (das sind ca. 90 stück) booten jeden Tag automatisiert.
Bei ein bis zwei „crashed“ der sync. Bei allen die ich mir angeschaut
hatte lag es daran, dass die Festplatte beim booten von linbo nicht
gefunden wurde. Ein reboot und die Möhre synct als wäre nichts gewesen.
Das scheint bei mir ein timingproblem des 6.xer Kernels zu sein.
Ich meine, dass das auch schon mit 6.6.2 von linbo 4.2.10 vorgekommen ist.
Derzeit bin ich dabei zu beobachten.
kann ich mir nicht vorstellen, 4.2.10 hat Kernel 6.6.2. Außerdem kannst
du noch zwei andere Kernelversionen auswählen.
das wäre das nächste was ich mal probieren werde.
Dazu gehe ich mal auf den alternativ longterm Kernel 6.1.65
Wenn das nicht hilft gehe ich auf den legacy 5.15.141
Ich hab das Gestern in einer FoBi mal vorgemacht, wie einfach und
schnell man linbo mit einem anderen kernel ausstattet: das ist einfach
genial.
Wie es geht ist schnell erklärt:
Man legt diese Datei an:
/etc/linuxmuster/linbo/custom_kernel
und füllt sie mit dem folgenden Text.
## use Linbo's alternative legacy kernel 5.15.141
#KERNELPATH="legacy"
## use Linbo's alternative longterm kernel 6.1.65
#KERNELPATH="longterm"
## currently active kernel image and modules used by the server
## path to kernel image 5.15.0.89
#KERNELPATH="/boot/vmlinuz-$(uname -r)"
## path to the corresponding modules directory
#MODULESPATH="/lib/modules/$(uname -r)"
## custom kernel image and modules
#KERNELPATH="/path/to/my/kernelimage"
## path to the corresponding modules directory
#MODULESPATH="/path/to/my/lib/modules/n.n.n"
wie man sieht ist alles auskommentiert: es ist also noch nichts passiert.
Will man den lonterm Kernel, dann entfernt man das KOmmentarzeichen am
Anfang der 4ten Zeile und ruft update-linbofs
auf.
Nach 2 Minuten ist das erledigt.
Jeder Client der danach gebootet wird, holt sich das neue linbo und
macht einen warmstart (oder auch nicht, wenn man nowarmstart gesetzt
hat: dann macht er einen richtigen reboot).
Danke, das mit dem alternativen Kernel werde ich beim naechsten Mal auch versuchen
Ich habe aber das Gefuehl, dass einige der 6er-Kernel auf einigen unserer Mainboards, teilweise recht alte Hardware, Probleme bereiten, die 5er scheinen besser zu passen, aber auch nicht alle. Ich musste auch auf unserem Mint auf 5.15.0-41-generic zurueck, da alle im Repo verfuegbaren 6er Probleme mit den Netzwerkinterfaces hatten, die neueren 5er auch, das macht keinen Spass.
Frueher (war alles besser) hatten wir diese Probleme weniger bis nie, ich konnte jegliche Kernel nutzen, immer die aktuellsten aus dem Repo bzw. wild durchwechseln.
Was bringen die neuen Kernel bei Linbo fuer Vorteile?
Ich hab schon genug damit zu tun das Mint am Rollen zu halten, wenn ich jetzt bei Linbo noch Kernelroulette spielen muss, dann dreh ich durch.
Ich muss aber auch dazuschreiben, dass wir teilweise zwei Netzwerkinterfaces haben, fuer die ein udev-Regelwerk Namen festlegt usw. usf. damit TIA aus einer VM die S7 connecten kann.
ich hatte heute morgen auch Probleme mit linbo 4.2.12 und dem zugehörigen neuesten Kernel.
Die Fehlermeldung ist ein Segmentation fault. Die GUI startet nicht, es liegt also nahe zu vermuten, dass das QT nicht starten will und segfaults wirft.
Das ganze steckt in einer Loop.
Heute morgen aufgetreten bei allen automatisch gestarteten Computern
Ein harter Reboot und alles war wie vorher.
vG, Tobias
ich hatte heute morgen auch Probleme mit linbo 4.2.12 und dem
zugehörigen neuesten Kernel.
Die Fehlermeldung ist ein Segmentation fault. Die GUI startet nicht, es
liegt also nahe zu vermuten, dass das QT nicht starten will und
segfaults wirft.
Das ganze steckt in einer Loop.
Heute morgen aufgetreten bei allen automatisch gestarteten Computern
Ein harter Reboot und alles war wie vorher.
das war also nur nach dem ersten booten nach dem Update des Servers?
Dann ist das was anderes als ich beschrieben habe.
Ja, bei mir: das erste Booten eines (alten) Clients nach dem Update auf linbo 4.2.12 und einem Reboot des Servers wg. Kernel-update (beides passierte freitags, Booten heute morgen ca. 6:30 Uhr).
Ob noch andere (neuere) Clients betroffen waren, konnte ich nicht herausfinden. Morgen werden wir sehen, ob es mehr als nur einmalig war.
LG, Tobias
Hallo zusammen, ich habe das jetzt noch reproduziert: Der Segfault passierte bei mir bei allen Geräten. Also nicht nur alte oder spezielle Computer. Scheinbar alle. Einmaliger harter reset ist die Lösung, danach scheint der segfault nicht mehr aufzutauchen.
