Hallo Thomas,
ich teste grade das Verteilen eines Images auf 17 Clients.
Hallo zusammen,
ich hab nochmal ein bisschen rumgespielt:
/etc/default/linbo-torrent
# default values for linbo-torrenthelper service provided by ctorrent
# thomas@linuxmuster.net
# 20220317
#
# note: you have to invoke 'linbo-torrent restart' after you have changed any values
#
# Exit while seed <SEEDHOURS> hours later (default 72 hours)
SEEDHOURS="8760"
# Max peers count (default 100)
MAXPEERS="100"
# Min peers count (default 1)
MINPEERS="1"
# Download slice/block size, unit KB (default 16, max 128)
SLICESIZE="128"
# Max bandwidth down (unit KB/s, default unlimited)
MAXDOWN=""
# Max bandwidth up (unit KB/s, default unlimited)
MAXUP="102400"
# Supplemental ctorrent options, separated by space (-v: Verbose output for debugging)
# OPTIONS="-S 10.16.1.1:2780"
# Timeout in seconds until rsync fallback (client only)
TIMEOUT="600"
# user to run ctorrent (server only)
CTUSER="nobody"
PIECELEN="524288"
Jetzt läuft’s super. Mir ist allerdings noch nicht klar, warum?!?
Vielleicht hilft’s ja…
Gruß,
Mathias
Moin,
habe den Fehler gefunden. Beim Wechsel von einem custom kernel zurück zum default kernel, wird das kernel image nicht wieder hergestellt. Habe das in Release 4.2.7 gefixt: Release Release 4.2.7-0 (lmn72) · linuxmuster/linuxmuster-linbo7 · GitHub
Leider funktioniert das github Repo mal wieder nicht. Ihr müsst das Paket also herunterladen und von Hand installieren.
VG, Thomas
Hallo Thomas,
schon gefixt?!? Du bist super!!!
Gruß,
Mathias
Hallo Thomas,
heute habe ich einen Client upgedatet und wollte ein neues Image erstellen.
Das Image wurde erstellt, aber nicht auf den Server hochgeladen?!?
Dann habe ich mich auf dem Client mit linbo-ssh angelemdet:
root@server:~# linbo-ssh lz-r99
Welcome to
_ _____ _ _ ____ ____
| | |_ _| \ | | _ \ / __ \
| | | | | \| | |_) | | | |
| | | | | . ` | _ <| | | |
| |____ _| |_| |\ | |_) | |__| |
|______|_____|_| \_|____/ \____/
LINBO 4.2.8-0: The Passenger | IP: 10.17.122.99 | MAC: 82:e6:79:17:1d:04
Linux 6.1.62 #1 SMP PREEMPT_DYNAMIC Mon Nov 13 21:07:21 CET 2023 x86_64 GNU/Linux
lz-r99: ~ # linbo_wrapper upload_image:1
Command : upload_image
OS number : 1
Uploading ubuntu2004.qcow2 to ...
Uploads a file from the cache to the server. Linbo user password is necessary.
Usage:
linbo_upload <password> <file> | [help]
For compatibility reasons legacy options are also accepted:
linbo_upload <server> <user> <password> <cache> <file>
Leider kann ich nicht sagen, ab wann diese Verhalten aufgetreten ist. Ich hab’ halt heute erst eine Image erstellt.
Gruß,
Mathias
Wenn Du jetzt 4.2.8-1 drauf haettest, dann wuesste ich wieso: Lmn 7.2 testing - #559 von irrlicht
Ich weiss jetzt aber nicht, ob 4.2.8-0 das gleiche Problem hatte, aber bei mir gingen Images auch nicht mehr auf den Server hoch, so wurde mir das Problem erst richtig bewusst. Die Clients starten ja weiter durch, laden Linbo halt von der Platte, die Images auch aus dem Cache.
Gruss Harry
Hallo Harry,
bei mir läuft linuxmuster-linbo7 4.2.9-0. Ich könnte mir vorstellen, dass das das gleiche Problem ist…
Gruß,
Mathias
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
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