Auf dem Client ist wohl noch 4.2.8 drauf, also musst Du den erstmal zurueckholen.
Hallo Harry,
Genau das war’s. Vielen Dank für den Tip.
Gruß,
Mathias
Hallo zusammen,
ein paar Frage hätte ich da noch. Vielleicht weiß einer von euch weiter…
In der Datei /etc/default/linbo-torrent steht bei mir:
# Timeout in seconds until rsync fallback (client only)
TIMEOUT="600"
Gestern abend habe ich ein Image auf 17 Clients verteilt und einige sind nach 300 s (nicht 600 s) auf rsync umgestiegen. Ist /etc/default/linbo-torrent die richtige Datei, um Einstellungen für den ctorrent vorzunehmen?
Nach dem Update auf linuxmuster-linbo7 4.2.9-0 gibt es nur noch ca. die Hälfte an Chucks:
Beim letzten mal waren es 62772, obwohl ich auf dem Client nur Einstellungen geändert habe. Manche Clients gehen nach 300s auf rsync. Das war beim letzten mal wesentlich besser. Wo kann ich das einstellen, wenn nicht in /etc/default/linbo-torrent?
Schon mal vielen Dank für eure Tips.
Gruß,
Mathias
Die Chunks werden eigentlich beim Erstellen des Torrents festgelegt. Bei uns hat sich da nichts geaendert mit den neuen Linbo, zumindest die /etc/default-linbo-torrent nicht.
Das ist ja das mekwürdige. Beim erstellen des Images hat sich die Größe der Chucks verdoppelt und dadurch die Anzahl der Chucks halbiert, obwohl ich an der Datei /etc/default/linbo-torrent nichts gemacht habe?!?
Ich vermute, dass da gar keine Chunkgroesse angegeben ist und demnach eine Default-Einstellung zum Zuge kommt. Vielleicht wurde ctorrent geupdated und da gibt es neue Grundeinstellungen?
Edith: Lmn 7.2 testing - #489 von thomas
Hallo Harry,
ich hab jetzt eine neues Image erstellt. Und diesmal mit PIECELEN="262144". Jetzt läuft’s wieder, wie ws sollte. Ob TIMEOUT="600" greift kann ich nicht sagen. Keiner der Clients hat das Timeout von 300 erreicht (was bei 57 Clients toll ist).
Gruß,
Mathias
1 „Gefällt mir“
Hallo Mathias,
war der letzte Post von Harry die Lösung? Wenn ja, bitte als solche markieren.
Danke!
Beste Grüße
Thorsten
Hallo @thomas ,
zweifle grade auch am Kernel in Linbo…
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.
Was tun?
VG, Tobias
Hallo Tobias,
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.
Dann hat der Client Version 4.2.8 im Cache. S.o.
VG, Thomas
Yes, danke, Thomas,
Das wars. Unwahrscheinlich, dass das nochmal auftaucht, aber jetzt bin ich (der 4.2.8 offensichtlich mitgemacht hat) gewappnet.
Gracias!
Hallo Thorsten,
Ja.
Allerdings dachte ich dass hier eher diskutiert wird, dass also kein Beitrag als Lösung gekennzeichnet wird…
Gruß,
Mathias
Hallo zusammen - dann nochmal am richtigen Ort:
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.
Ein entsprechendes Issue habe ich angelegt.
Viele Grüße
Thomas
1 „Gefällt mir“
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 RUNTIMEIn 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?
Viele Grüße,
Michael
Hallo Michael,
leider nein. Das ist eine sophomorix-Baustelle. Weiß @jeffbeck evtl. was dazu?
VG, Thomas
Hallo Thomas,
hast du schon mal warmstart oder forcegrub probiert?
VG, Thomas
Guten Morgen Thomas.
Ich fürchte, ich kann es nicht nachvollziehen. Ich habe
Kernel = vmlinuz.old
Initrd = initrd.img.old
als alternativen Kernel in die start.conf eingetragen und mit linuxmuster-import-devices in die grub configs übernommen. Danach mit
KernelOptions = quiet splash dhcpretry=5
und mit
KernelOptions = quiet splash dhcpretry=5 forcegrub warmstart=no
gebootet. Beide Male wurde korrekterweise der old-Kernel gebootet. 
VG, Thomas
könnte eine neue Version des Symptoms:
sein.
VG. Tobias
Hallo @thomas
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.
Feine Sache!
Danke und viele Grüße
Thomas