Lmn 7.2 testing

baumhof · 3. März 2023 um 19:09

Hallo Michael,

Es muss doch einfach |jammy.postsync| heißen,

ja: das ist korrekt.

Die Rechte stimmen auch.

LG

Holger

Michael · 3. März 2023 um 19:19

Ok – mit den geänderten Optionen und einem zwischenzeitlichen Partitionieren/Formatieren des Clents funktioniert das Postsync nun wieder. Besten Dank!

Ich hatte nicht mehr auf dem Schirm, dass die Postsync-Datei nur nach dem Formatieren übertragen wird. Nur aus Interesse: Ist das sinnvoll? Wäre es nicht besser, wenn die auch bei Sync+Start vom Server geholt wird?

foer · 3. März 2023 um 20:11

Ich hätte das auch gerne als Default-Verhalten. Ich habe mir diese Funktionalität durch die Hintertür eingebaut. Die letzte Zeile in meinem Postsyncskript lautet:

rsync --progress -r $LINBOSERVER::linbo/images/jammy/jammy.postsync /cache/

Ist nicht schön, funktioniert aber seit Jahren prima. Eine Änderung am Skript auf dem Server landet also beim nächsten Postsync auf dem Client-Cache…ist irgendwie auch witzig wenn sich ein Skript selber rsynct.

cweikl · 3. März 2023 um 20:32

Hallo zusammen,
danke für die Diskussion. Ich habe das alles bei mir umgesetzt und getestet. Funktioniert. Entsprechend habe ich die Doku angepasst und aktualisiert.

Bitte kontrolliert das mal, ob das so alles passt. Bei dem universellen Postsync-Script hast Du Dominik wohl noch ein paar weitere Eintragungen (Berechtigungen) etc. und ggf. auch im Verzeichnis postsync.d ein paar hilfreiche Scripte, die wir mit dem universellen Postsync Thomas als PR zur Verfügung stellen könnten, damit diese unter /srv/linbo/examples/postsync/generic.postsync bzw. /srv/linbo/examples/postsync/postsync.d/ abgelegt werden.

VG
Chris

thomas · 4. März 2023 um 13:57

Das ist nicht so. Die Postsync-Datei wird jedes Mal geholt, wenn ein neues Image auf dem Server vorliegt (natürlich auch, wenn das Image noch nicht im Cache ist). Aber es ist klarerweise wünschenswert, dass sie bei jedem Sync vom Server aktualisiert wird.

VG, Thomas

thomas · 7. März 2023 um 19:54

Guten Abend allerseits!

Es gibt jetzt linuxmuster-linbo7 4.1.26:

Update kernel to 6.2.2 (62b8e01).
Update reg and postsync files on every sync (c2c5048).
Hide diff error message if local grub config file misses (483aded).

postsync- und reg-Dateien werden jetzt bei jedem Sync aktualisiert, auch wenn kein neues Image heruntergeladen werden muss.

VG, Thomas

Michael · 8. März 2023 um 11:14

Hallo.
Ich habe es ausprobiert … die postsync-Datei wird jetzt direkt beim Sync+Start mit übertragen. Super!
Viele Grüße,
Michael

rettich · 11. März 2023 um 08:14

Hallo zusammen,
auf meinem Testsystem läuft auf dem Server pykms (zur aktivierung der Windows-Clients).
Dazu lauscht pykms auf dem Port 1688. Leider dringt seit dem Upgrade auf 7.2 keine Anfrage mehr durch.
Läuft auf dem Server eine Firewall? ufw status liefert Status: inactive?

Gruß,
Mathias

rettich · 11. März 2023 um 09:46

Hallo zusammen,
es liegt nicht an einer server-Firewall. pykms hat ein Problem mit ubuntu 22.04…
Gruß,
Mathias

foer · 11. März 2023 um 21:29

Hi @thomas ,
das hat mich jetzt einige Stunden bis zur Erkenntnis gekostet…dachte erst, in meinem Netzwerk ist was schief…
Bei Linbo 4.1.26 gibt es ein Problem mit dem ctorrent. Mit Linbo 4.1.26 habe ich eine maximale Uploadrate von ca. 17100K/s. Bei allen Linboversionen < 4.1.26 ist die Uploadrate bei > 80000K/s, meistens sogar über 90000K/s.
Kannst du mal danach schauen?

VG Dominik

thomas · 12. März 2023 um 11:49

Hallo Dominik,

danke für die Info. Checke ich morgen.

VG, Thomas

rettich · 13. März 2023 um 17:54

Hallo @thomas ,
Nur zur Info: Ich wollte auf meinem Testsystem einen Rechner aufnehmen:

und bekam diese Fehlermeldung:

Gruß,
Mathias

dorian · 13. März 2023 um 21:30

Das sieht für mich so aus, als hätte sich limbo_cmd dahingehend geändert, dass man andere Argumente übergeben muss. Da die Gui noch von den alten Argumenten ausgeht, geht das dann schief. @thomas ?

thomas · 14. März 2023 um 08:44

Hier. Was geht?

Sieht so aus, dass linbo_register die Parameter falsch interpretiert. Ich schau danach. linbo_cmd ist eh nur noch eine Kompatibilitätsschicht für das Gui. Die eigentliche Arbeit wird von den linbo_* Befehlen erledigt.

thomas · 14. März 2023 um 09:24

Hallo Dominik,

konnte ich jetzt auf meinem Testsystem so nicht beobachten. Mit 4.1.26 waren die DL-Raten sogar geringfügig besser:

4.1.25

- 1/0/2 [27031/30267/30267] 6757MB,0MB | 206015,0K/s | 132352,0K E:0,1 
\ 1/0/2 [27423/30267/30267] 6855MB,0MB | 198560,0K/s | 100352,0K E:0,1 
| 1/0/2 [27920/30267/30267] 6980MB,0MB | 193427,0K/s | 127232,0K E:0,1 
/ 1/0/2 [28773/30267/30267] 7193MB,0MB | 193141,0K/s | 218368,0K E:0,1 
- 1/0/2 [29223/30267/30267] 7305MB,0MB | 190443,0K/s | 115200,0K E:0,1 
\ 1/0/2 [29912/30267/30267] 7478MB,0MB | 186686,0K/s | 176256,0K E:0,1   
Download complete.
Total time used: 0 minutes.
Seed for others 0 hours
| 0/0/2 [30267/30267/30267] 7566MB,0MB | 0,0K/s | 90880,0K E:0,1 Connecting
real    0m 40.97s
user    0m 12.72s
sys     0m 5.55s

4.1.26

- 1/0/2 [25121/30267/30267] 6280MB,0MB | 220865,0K/s | 187904,0K E:0,1 
\ 1/0/2 [26107/30267/30267] 6526MB,0MB | 222524,0K/s | 252416,0K E:0,1 
| 1/0/2 [26939/30267/30267] 6734MB,0MB | 222851,0K/s | 212864,0K E:0,1 
/ 1/0/2 [27803/30267/30267] 6950MB,0MB | 222562,0K/s | 221184,0K E:0,1 
- 1/0/2 [28675/30267/30267] 7168MB,0MB | 223826,0K/s | 223360,0K E:0,1 
\ 1/0/2 [29328/30267/30267] 7332MB,0MB | 219842,0K/s | 167040,0K E:0,1 
Download complete.
Total time used: 0 minutes.
Seed for others 0 hours
| 0/0/2 [30267/30267/30267] 7566MB,0MB | 0,0K/s | 120192,0K E:0,1 Connecting
real    0m 35.86s
user    0m 12.67s
sys     0m 5.32s

Welcher Netzwerktreiber ist unter Linbo denn geladen?

VG, Thomas

thomas · 14. März 2023 um 18:57

Lt. Screenshot ruft das Gui folgenden Befehl auf:
linbo_cmd register *** linbo 10.16.1.1 itg ...

Die Server-IP also an 3. Stelle. Wenn ich in linbo_cmd v4.0 nachschaue erwartet die register-Funktion die Server-IP an 1. Stelle (Zeile #3162):

# register server user password room hostname ip group role

Und wenn ich linbo_cmd register so aufrufe, klappt es auch in v4.1. Also IMHO muss das Gui da irgendwas anders machen als zuvor.

VG, Thomas

foer · 14. März 2023 um 20:07

Hallo Thomas (@thomas ),
ich muss das nach weiteren Tests differenzieren:

Linbo. 4.1.25 und alle Vorgänger bis Linbo 2.3.x

überhaupt keine Probleme

Linbo 4.1.26:

Virtualbox Testsystem: keine Probleme - hohe Raten
Produktive Umgebung - virtueller Proxmoxclient: keine Probleme - hohe Raten
Produktive Umgebung - Blechclients: extrem schlechte Raten

Ich habe viele verschiedene Clients aber alle haben irgendeine Butterbrot Realtek Netzwerkkarte verbaut, wie sie halt in 90% der Standartmainboards steckt. Geladen wird bei allen Linboversionen immer der selbe Netzwerktreiber: r8169.

Hier mal stellvertretend eine Messung von einem Client mit 4.1.25 und 4.1.26. Habe vier verschiedene Clients getestet und alle zeigen dieses Problem:

Linbo 4.1.25: r8169

- 1/4/9 [26652/29594/29594] 6663MB,0MB | 100635,0K/s | 101168,0K E:0,1
\ 1/4/9 [27048/29594/29594] 6761MB,0MB | 100659,0K/s | 101360,0K E:0,1
| 1/4/9 [27444/29594/29594] 6860MB,0MB | 100689,0K/s | 101312,0K E:0,1
/ 1/4/9 [27840/29594/29594] 6960MB,0MB | 100753,0K/s | 101472,0K E:0,1
- 1/4/9 [28235/29594/29594] 7058MB,0MB | 100763,0K/s | 101088,0K E:0,1
\ 1/4/9 [28631/29594/29594] 7157MB,0MB | 100781,0K/s | 101296,0K E:0,1
| 1/4/9 [29024/29594/29594] 7256MB,0MB | 100792,0K/s | 100768,0K E:0,1
/ 1/4/9 [29417/29594/29594] 7354MB,0MB | 100917,0K/s | 100512,0K E:0,1
Download complete.
Total time used: 1 minutes.
Seed for others 0 hours
- 0/4/9 [29594/29594/29594] 7398MB,0MB | 0,0K/s | 45248,0K E:0,1 Connecting

Linbo 4.1.26: r8169

/ 3/0/3 [29104/29594/29594] 7276MB,0MB | 17487,0K/s | 17616,0K E:0,1
- 3/0/3 [29174/29594/29594] 7293MB,0MB | 17509,0K/s | 17568,0K E:0,1
\ 3/0/3 [29243/29594/29594] 7310MB,0MB | 17543,0K/s | 17712,0K E:0,1
| 3/0/3 [29311/29594/29594] 7327MB,0MB | 17577,0K/s | 17616,0K E:0,1
/ 3/0/3 [29380/29594/29594] 7345MB,0MB | 17598,0K/s | 17568,0K E:0,1
- 3/0/3 [29449/29594/29594] 7362MB,0MB | 17633,0K/s | 17712,0K E:0,1
\ 3/0/3 [29518/29594/29594] 7379MB,0MB | 17636,0K/s | 17616,0K E:0,1
| 2/0/3 [29587/29594/29594] 7396MB,0MB | 17627,0K/s | 17568,0K E:0,1
Download complete.
Total time used: 6 minutes.
Seed for others 0 hours
/ 0/0/3 [29594/29594/29594] 7398MB,0MB | 0,0K/s | 1680,0K E:0,1 Connecting

Ich könnte mir vorstellen, dass das was mit dem neuen Kernel 6.2.x von Linbo 4.1.26 zu tun hat. Der Unterschied ist halt eklatant 1 Minute vs. 6 Minuten Downloadzeit.
Ich wüßte jetzt nicht, wo ich drehen kann oder was ich testen sollte um das Problem genauer zu debuggen. Ich bin mir aber sicher, das in the wild viele dieses Problem haben, weil meine Netzwerkkarten wirklich Massenprodukte sind.

Also was tun? Ich bin jetzt wieder bei 4.1.25 und habe Linbo auf hold gesetzt.

VG Dominik

Sascha · 15. März 2023 um 06:56

Oh Mann, Deine Probleme hätte ich gerne…10000 K/s ist aufgrund der Installation bei uns oft das höchste der Gefühle, wir haben sogar einen Raum, da ist die Verkabelung so schlecht, dass die Rate auf unter 1000K/s fällt sobald mehr als zwei Clients syncen… Und weil wir uns gegen die Windowsfraktion nicht durchsetzen können, dürfen über diese Leitung cloops mit 46GB Größe verteilt werden…da kannst Du Freitags Abends mit dem syncen anfangen, wenn das Montag fertig werden soll.

Aber klar, dass ist kein Grund, die Ursache für den mglw. softwareseitig verursachten Faktor 6 hier nicht zu suchen.

Gruß
Sascha

thomas · 15. März 2023 um 09:28

Das habe ich befürchtet. Du kannst mal versuchen den alternativen r8168-Treiber zu verwenden. Dazu musst du in der Linbo-Kernelzeile modprobe.blacklist=r8169 loadmodules=r8168 hinzufügen.

thomas · 15. März 2023 um 13:56

Das sieht so aus, aber weder im Kernel-Changelog noch im Config-Diff gibt es irgendeinen Hinweis, dass es bzgl. r8169 eine Änderung gab.