Sync & start läd immer wieder die Daten vom server

Seit kurzem beobachten wir das ein sync statt die aktuellen Daten aus der cache Partition zu nehmen, IMMER einen download vom Server durchführt.
Das ist ein großes Problem, da wir morgens die Rechner per WOL aufwecken und mit sync starten.
Durch den imensen Traffic rennen Clients in einen DHCP bzw. TFTP timeout und bleiben beim booten hängen.
Hat jemand eine Erklärung für dieses Verhalten?

Hallo,

das sind zwei Probleme:

  1. immer download bei sync
  2. TFTP timeout wenn zuviele runterladen

ich denke sie hängen zusammen.
Anscheinend ist die torrentdatei nicht korrekt erstellt worde (wurden Images händisch umbenannt?), deswegen klappt torrent nicht, weswegen nach 2 Minuten in rsync zurückgefallen wird, welches Netz und server so belastet, dass es zum Timeout für spätere kommt.

Jetzt erstmal die torrentdatei nmeu erstellen lassen durch:
/etc/init.d/linbo-bittorrent restart .cloop force

Danach Client booten und schauen, ob per torrent beim sync downgeloaded wird.
Wenn das geht, dann nochmal starten und schauen, ob wieder downgeloaded wird beim sync.

LG

Holger

Hallo Holger,

Ja

Nein bittorrent funktioniert es wird nicht rsync benutzt

Ich hatte das .torrent schon manuell neu erstellt.
Aber auch nach diesem Befehl, wird statt sync vom cache immernoch bt angeworfen.

Hallo,

Haben die Partitionen Labels ?
Ich habe solches Verhalten erlebt wenn die Labels fehlen ( vielleicht weil die Cache Partition nicht gefunden ist ).

Gruß

Arnaud

Hallo Arnaud,

Ja, haben sie. Die Label sind vorhanden und korrekt. Die cache Partition wird erkannt und benutzt.
Nur scheint aus irgendeinem Grund nicht erkannt zu werden das in der cache Partition schon die cloop vorhanden und komplett ist^^

Ok, dann gibt es vielleicht eine Info in den Logs.
Man kann es in /var/log/linuxmuster/linbo/HOSTNAME.linbo-remote finden.

Gruß

Arnaud

Hallo Michael,

dann mach mal folgendes:

  1. windows booten und die Windowspartition checken (beide Haken setzen, gegebenenfalls ungesynct rebooten)
  2. in linbo booten und den lokalen cache mounten. Das darin enthaltene Windowsimage löschen (cloop löschen reicht)
  3. auf dem server das windows cloop löschen oder wegbewegen
  4. neues Image erstellen und hochladen
  5. testen

LG

Holger

Hallo Holger,

an der Schule gibts keine „nativen“ Windows-Clients…das sind alles Linux-Clients. Windows gibt nur als VM.

Gruß
Thomas

Ok, ich hab den Fehler gefunden.
Was passiert ist, weiß ich nicht genau, aber ich nehme an jemand hat versehenlich in linbo einen image upload unter dem gleichen filename wie das alte image gestartet und dann abgebrochen.
Dadurch war das Image nur noch 200MB groß und hat natürlich nicht mehr funktioniert.

Ich habe dann die Kopie des Images auf den richtigen filename zurück kopiert und das .torrent neu erzeugt. Dadurch war es möglich Rechner wieder funktional zu Imagen. Allerdings mit dem beschriebenen Effekt, dass sync immer downloaded statt das image aus dem cache zu nutzen.

Jetzt stand in der .info Datei zum Image eine falsche imagesize. Korrigiert man die imagesize auf die tatsächliche Größe des Images geht alles wieder wie gewohnt und ein sync benutzt das Image aus dem cache.

Holger hatte insofern recht, also dass linbo beim sync tatsächlich direkt auf rsync zurückgegriffen hat. Das steht allerdings nur im linbo.log und ist in der linbo gui nicht erkennbar.

Weiß jemand für die Zukunft wie ich den Prozeß der Erzeugung dieser Metafiles manuell auf ein cloop Image anwerfen kann?

FYI: Die Geräte müssen nach der .info Anpassung noch einmalig vom Server gesynct werden.
Ich habe jedenfalls keinen Weg gefunden das zu verhindern, obwohl das Image bereits in der richtigen Görße im cache vorhanden ist.

Hallo Michael,

mein Vorschlag: einmal neues Image erstellen und verteilen hätte das Problem also auch gelößt.

LG

Holger

Und 400+ Clients neu imagen und 180GB vm pro Client verteilen - nicht wenn ich drum rum komme :slight_smile:
Das Problem wird sich so vermutlich nicht wiederholen von daher bin ich ja soweit zufrieden. Danke an alle Poster!

Micha