Mit diesem update-linbofs-pre-hook-Skript reduziert sich die Größe des linbofs64.lz auf ca. die Hälfte. Es löscht einige nicht benötigte Modulverzeichnisse.
#!/bin/bash
#
# /var/lib/linuxmuster/hooks/update-linbofs.pre.d/remove_unwanted_modules
#
# removes unwanted modules from distro kernel
#
source /usr/share/linuxmuster/linbo/helperfunctions.sh
wanted="block crypto drivers fs lib net"
for item in lib/modules/*/kernel/*; do
dir="$(basename "$item")"
stringinstring "$dir" "$wanted" || rm -rf "$item"
done
depmod -a -b . "$(basename $(ls -d lib/modules/*))"
Bei der Neuaufnahme eines Rechners mit Linbo startet nur das Minimal Linux mit Reboot oder Shutdown. Wenn der Rechner über die Schulkonsole aufgenommen wurde, startet Linbo normal.
Bei der Neuaufnahme eines Rechners mit Linbo startet nur das Minimal
Linux mit Reboot oder Shutdown. Wenn der Rechner über die Schulkonsole
aufgenommen wurde, startet Linbo normal.
das ist normale.
Wird ein Rechner über linbo auf dem Client aufgenommen, so wird er in
der devices.csv eingetragen: es fehlt aber noch der Befehl
linuxmuster-import-devices
auf dem Server.
Den muss man noch absetzen.
Macht man es in der WebUI, dann wird am Ende im Hintergrund dieser
Befehl ausgeführt.
Du kannst also hingehen und 5 oder 10 Rechner per linbo auf dem Client
aufnehmen und dann einmal auf dem Server den import starten: dann sind
sie richtig drin.
Linbo kann den Befehl nach dem Aufnahmen auf dem Server nicht triggern.
Hallo zusammen,
nachdem ich alle Clients auf optimale Download-Geschwindigkeit gebracht habe , habe ich mal ein paar clients gleichzeitig syncen lassen:
Die Clients im Lehrerarbeitszimmer wurden vorher in Linbo gestartet.
10 Clients wurden mit linbo-remote -r Raum -c partition,format,initcache,sync:1,halt
dazu gebracht, das Image nochmal vollständig herunter zu laden.
Und das war zu beobachten:
Die Clients haben das Image ausschlißlich vom Server gezogen:
So sah’s auf dem Server aus:
Der liefert, was geht.
Eigentlich hätte ich gedacht, dass sich die Clients gegenseitig die Dateihäppchen zuschicken. Stattdessen holen Sie alles vom Server. Notfalls warten sie, bis sie wieder was bekommen.
Hab’ ich da irgendwo wasfalsch eingestellt?
Gruß,
Mathias
Ich weiß nicht wie es in der neuesten Linbo-Version aussieht, aber hier im Linbo 4.1 sieht es so aus:
ungünstige Torrent-Default-Konfiguration
Der Torrent-Client „ctorrent“ (siehe Ubuntu Package ctorrent - sources - UserGuide) nutzt die Default-Konfiguration Min peers count (default 1). Das bedeutet, solange ein Linbo-Client einen Torrent-Peer sieht und das kann der Linbo-Server selbst sein, wird er vom Tracker keine neue Peer-Liste abfragen.
Der Bittorrent-Tracker (siehe bttrack.bittornado • man page) serverseitig, nutzt --reannounce_interval seconds the number of seconds downloaders should wait between reannouncements (defaults to 1800). Das bedeutet der Tracker auf dem Linbo-Server wird nur alle 30 Minuten eine aktuelle Liste aller Peers an alle Peers senden.
Das deckte sich dann auch mit den Beobachtungen in unseren IT-Lehrsälen bei 30-50 Rechnern im Abstand von je einer Sekunde aufgeweckt:
Die ersten Clients sehen nur den Linbo-Server, die letzten Rechner sehen fast alle Peers und sind dadurch teilweise eher mit Download fertig.
90% der Rechner laden nicht hoch (im Status auf dem Client zu sehen), da sie nicht angefragt werden.
Das Verhalten änderte sich erst, als wir den Torrent-Client auf dem Linbo-Server auf 900 Mbps gedrosselt hatten, u.a. damit auch die TFTP-Downloads der PXE-Umgebung nicht verhungern, während Images verteilt werden. Da waren teilweise nicht mal 30 KB/s drin, während andere Rechner ihr Image vom Server luden.
Mit der letzten /etc/linuxmuster/linbo/custom_kernel mit anschließendem update-linbofs ändert sich leider nichts mehr.
Hast du mir einen Tipp?
Gruß,
Mathias
Seltsames verhalten. Iwas hindert das alte Linbo daran das geänderte Linbo vom Server zu holen. In dem Fall müsste die Methode mit dem erzwungenen Netboot helfen.
VG
Das meinte ich weiter oben schon - dass zwar ein eigener Kernel jetzt klappt, aber wenn man custom_kernel wieder weg nimmt, dann evtl. der „linbo-standard-kernel“ nicht richtig eingebunden wird (oder eben sonst etwas schief geht).
Netboot habe ich (meine ich) versucht, kann ich aber morgen noch einmal testen.
Wenn wir jetzt den aktuellen HWE-Kernel nehmen funktionieren die beiden Geräte, die Probleme gemacht haben.
Dafür booten jetzt andere Lenovos nicht mehr richtig - ich hoffe aber, da fehlt nur ein Kernel-Parameter…
Tja, mehr Flexibilität heißt mehr Möglichkeiten heißt mehr Arbeit
So sieht’s bei allen Clients aus.
Wenn ich das richtig interpretiere, bedeutet
2808MB,0MB
2808MB downgeloaded und 0MB upgeloaded. Das heißt, die Clients teilen ihre Daten nicht. Da stimmt irgendetwas mit dem torrent nicht, oder?
Kann man da rigendwo noch nachjustieren?
Gruß,
Mathias
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…
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.