gerade sehe ich das problem, dass er an einem client „localboot“ in der cmdline hat. Warum?
ich habe KERNELPATH=„longterm“ eingeschalten und update-linbofs ausgeführt.
An einem client sehe ich, dass per PXE der 6.1 Kernel booten.
An dem problematische sehe ich, dass ich per linbo-remote in den 6.6-er kernel komme. Der hat also nicht das custom-kernel geladen bzw. linbo auf der platte upgedatet.
Allerdings kann ich kein „initcache:torrent“ ausführen, denn er bricht mit „local mode“ ab.
auch wenn ich nach KERNELPATH nicht mehr exportiere und somit zurück auf 6.6er-kernel gehe, landet der client im „localmode“.
Ich stelle auch fest, dass in.tftpd viel „Connection refused“ im syslog meldet. Kann auch normal sein. Fällt nur auf.
d.h., dass Linbo aus dem lokalen Cache geladen wurde. Wird benutzt, um festzustellen, ob auf dem Server nach Aktualisierung geschaut werden soll. Also Ok.
mir ist aufgefallen, dass ein alternativer Linux-Kernel aus der start.confbei UEFI-Systemen nicht übernommen wird.
Wir haben einige Surface-Geräte und für die ist ein eigener Kernel im Image. Bisher wurde dieser (vmlinuz-surface/initrd.img-surface) auch gebootet, so wie er in der start.conf angegeben war. Derzeit bootet aber nur vmlinuz/initrd.img, egal, was ich angebe.
Erneut: ob das 7.2-spezifisch ist, kann ich nicht sagen, die letzte Synchronisation eines Surface-Gerätes liegt lange zurück.
Man bekommt das auch über Postsync-Skripte repariert, aber es wäre schön, wenn das grundsätzlich möglich wäre.
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.
