alle eventuellen Hook-Skripte deaktiviert, update-linbofs…
Wenn man ESC drückt, sieht man manchmal auch für einen Moment ein Bild. Auf jeden Fall sehr seltsam - noch nie so beobachtet.
Zunächst habe ich an ein defektes Gerät gedacht - aber als das dann auch mit anderen nicht ging…
dhcpretry war eh eingestellt (testweise habe ich es entfernt), aber er bekommt ja eine IP und holt sich die Dateien vom Server.
Das Problem tritt auch auf völlig neuen, unbespielten Rechnern auf. Sowohl beim Booten aus dem Netz als auch vom USB-Stick.
Irgendeine Hardwarekombination scheint da fatal zu sein und zum beschriebenen Fehler zu führen…
Viele Grüße
Thomas
PS: Auch Linbo im Debug-Modus startet nicht, da der Fehler vorher passiert. Insofern kommt man auch nicht auf die Rechner, um nachzuschauen. Ein normales Ubuntu startet auf den Rechnern problemlos. Im Moment hoffe ich, dass es erst einmal bei den beiden Geräten bleibt…
mal eine erste Beobachtung: mit dem 5.15-er Kernel des Servers booten die betroffenen Rechner wieder! Also irgendeine Inkompatibilität mit dem eingebauten 6er-Kernel.
Testweise (weil ich auch so Sachen wie Bios-Update gemacht habe) habe ich die Datei custom_kernel wieder entfernt und update-linbofs ausgeführt. Jetzt meckert Linbo beim Netzwerk-Boot, dass es die Module (fan, nbd, ntfs3) für 5.15 nicht findet und bricht den Boot ab (Option Neustart/Shutdown).
Fehlt da evtl. ein Default-Wert, wenn man den eigenen Kernel rausnimmt?
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