Lmn 7.2 testing

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.

foer · 15. März 2023 um 16:39

Hi Thomas (@thomas )

Habe ich gemacht. Hat tatsächlich bei 3/4 der Blechclients das Problem beseitigt und die Raten sind wieder ok. Mega. Beim anderen Viertel unterstützt der r8168 die Netzwerkkarte nicht…da ist es halt Mist. Die Clients muss ich dann in eine eigene Hardwaregruppe packen.

Also von daher ist die Situation so lala. Zumindest kann man mal in die Doku schreiben, dass das Problem ggf. durch wechseln des Treibers gelöst werden kann. Insgesamt macht das die Sache schon komplexer und vor allem vor dem Hintergrund, dass diese Realtekkarten überall in 1000 Varianten verbaut sind.

Ich habe mich auch mal versucht schlau zu machen, was von 6.1 zu 6.2 passiert ist. Keine Chance für mich das zu durchschauen. Der Netzwerkstack ist ja riesig und welche Änderung da an welcher Stelle dazu geführt hat, dass die Durchsatzraten so einbrechen…keine Ahnung.

Ist es deine Strategie immer den aktuellen stable Kernel in Linbo einzubauen? Ansonsten wäre der 6.1er ja LTS.

VG
Dominik

thomas · 16. März 2023 um 09:39

Moin moin!

Es gibt linuxmuster-linbo7 4.1.27:

Das hat bisher immer gut geklappt. Ich habe in meiner Schule mehrere Desktop-Rechner, die mit r8169/r8168 laufen. Da konnte ich keine signifikanten Unterschiede mit den verschiedenen Kernel- und Modulversionen beobachten.
Teste mal bitte die Linboversion mit der rtl_nic-Firmware bei den r8169-Clients. Falls das nicht hilft, gehen wir auf den 6.1er LTS zurück.
BTW, der Parameter loadmodules r8168 kann weggelassen werden, blacklisten reicht.

Nochn Tipp: Mit dmesg kann mensch kontrollieren, ob ein Modul die Firmware vermisst. Bitte melden, ob weitere Firmware benötigt wird.

VG, Thomas

foer · 16. März 2023 um 11:36

Hallo Thomas,

vielen Dank erst Mal für deinen Einsatz hier! Mega!

habe ich gemacht. Das hat bei einer Hardware eine Verbesserung gebracht, allerdings nur um den Faktor 2. Bei den anderen Clients verändert es nichts am Problem, schadet aber auch nicht…also leider nicht der große Wurf.

Ich habe aber noch weiter getestet und einige teilweise „esoterische“ Dinge herausbekommen:

Man muss den r8169 nicht blacklisten, sondern das loadmodules=r8168 als Kerneloption in Linbo einfügen. Das abartige ist dann, dass alle Kisten trotzdem den r8196 benutzen aber die Durchsatzraten sind wieder wie bei linbo < 4.1.26?? What!? Den Tipp habe ich einige Male bei ähnlich gelagerten Problemen in der Kernel Mailingliste gefunden aber eine Erklärung dafür nicht. Ich könnte mir vorstellen, dass das laden des Moduls andere Module aus dem Netzwerkstack nachläd/ initialisiert, die dann dem r8169 „helfen“ optimal zu laufen…strange!
Die Kisten, die nicht mit dem r8168 klar kamen, waren jetzt doch dazu zu bewegen zu funktionieren. Dafür muss der Kernelparameter pcie_aspm=off ins Linbo. Anscheinend wird der Treiber schon geladen und die Netzwerkkarte initialisiert, dann aber vom Powermanager des Kernels abgeschaltet…der Parameter deaktiviert das powermanagement. Prinzipiell brauche ich das jetzt aber nicht mehr, weil der o.g. Zaubertrick funktioniert

Also habe ich jetzt den Zustand, dass mit den passenden Kerneloptionen alles optimal läuft. An dieser Stelle wäre es jetzt schon wichtig, dass mal andere testen, ob das ein gängiges Verfahren ist oder ob es bei anderen Varianten von Realteck-Karten Probleme gibt.

Also für den Moment könnte der Kernel bei 6.2.x bleiben. Wenn bei anderen das Problem durch das loadmodule=r8168 nicht gelöst werden kann, dann kann man ja nochmal darüber nachdenken, ansonsten ist ein möglichst aktueller Kernel in Linbo schon nice.

VG
Dominik