Linbo 4.2.0 testing

Clientpflege linbo
81

Ich vermute, dass da gar keine Chunkgroesse angegeben ist und demnach eine Default-Einstellung zum Zuge kommt. Vielleicht wurde ctorrent geupdated und da gibt es neue Grundeinstellungen?
Edith: Lmn 7.2 testing - #489 von thomas

82

Hallo Harry,
ich hab jetzt eine neues Image erstellt. Und diesmal mit PIECELEN="262144". Jetzt läuft’s wieder, wie ws sollte. Ob TIMEOUT="600" greift kann ich nicht sagen. Keiner der Clients hat das Timeout von 300 erreicht (was bei 57 Clients toll ist).
Gruß,
Mathias

1 „Gefällt mir“
83

Hallo Mathias,

war der letzte Post von Harry die Lösung? Wenn ja, bitte als solche markieren.
Danke!

Beste Grüße

Thorsten

84

Hallo @thomas ,

zweifle grade auch am Kernel in Linbo…

gerade sehe ich das problem, dass er an einem client „localboot“ in der cmdline hat. Warum?

ich habe KERNELPATH=„longterm“ eingeschalten und update-linbofs ausgeführt.
An einem client sehe ich, dass per PXE der 6.1 Kernel booten.
An dem problematische sehe ich, dass ich per linbo-remote in den 6.6-er kernel komme. Der hat also nicht das custom-kernel geladen bzw. linbo auf der platte upgedatet.
Allerdings kann ich kein „initcache:torrent“ ausführen, denn er bricht mit „local mode“ ab.
auch wenn ich nach KERNELPATH nicht mehr exportiere und somit zurück auf 6.6er-kernel gehe, landet der client im „localmode“.

Ich stelle auch fest, dass in.tftpd viel „Connection refused“ im syslog meldet. Kann auch normal sein. Fällt nur auf.

Was tun?
VG, Tobias

85

Hallo Tobias,

d.h., dass Linbo aus dem lokalen Cache geladen wurde. Wird benutzt, um festzustellen, ob auf dem Server nach Aktualisierung geschaut werden soll. Also Ok.

Dann hat der Client Version 4.2.8 im Cache. S.o.

VG, Thomas

86

Yes, danke, Thomas,

Das wars. Unwahrscheinlich, dass das nochmal auftaucht, aber jetzt bin ich (der 4.2.8 offensichtlich mitgemacht hat) gewappnet.
Gracias!

87

Hallo Thorsten,

Ja.
Allerdings dachte ich dass hier eher diskutiert wird, dass also kein Beitrag als Lösung gekennzeichnet wird…
Gruß,
Mathias

88

Hallo zusammen - dann nochmal am richtigen Ort:

mir ist aufgefallen, dass ein alternativer Linux-Kernel aus der start.confbei UEFI-Systemen nicht übernommen wird.

Wir haben einige Surface-Geräte und für die ist ein eigener Kernel im Image. Bisher wurde dieser (vmlinuz-surface/initrd.img-surface) auch gebootet, so wie er in der start.conf angegeben war. Derzeit bootet aber nur vmlinuz/initrd.img, egal, was ich angebe.

Erneut: ob das 7.2-spezifisch ist, kann ich nicht sagen, die letzte Synchronisation eines Surface-Gerätes liegt lange zurück.

Man bekommt das auch über Postsync-Skripte repariert, aber es wäre schön, wenn das grundsätzlich möglich wäre.

Ein entsprechendes Issue habe ich angelegt.

Viele Grüße
Thomas

1 „Gefällt mir“
89

Hallo Thomas,
das kann ich bestätigten! Es ist deutlich spürbar, dass es flotter läuft! :+1:

Beim Durchlauf von linuxmuster-import-devices habe ich allerdings eine (neue?) Meldung, die ich mir nicht erklären kann: Ich bekomme für die VM, die als Master dient, zwei Mal das hier:

ERROR in Sophomorix::SophomorixSambaAD::AD_computer_create:
   0000202F: samldb: spn[HOST/SERVER] would cause a conflict
   * serverraum must be created RUNTIME

In der devices.csv gibt es aber nur einen Eintrag für diese Maschine. Hängt das evtl mit den Beobachtungen von @thoschi zusammen, dass da irgendwo Reste im AD stehen bleiben??
Hast Du eine Idee?

Viele Grüße,
Michael

90

Hallo Michael,

leider nein. Das ist eine sophomorix-Baustelle. Weiß @jeffbeck evtl. was dazu?

VG, Thomas

91

Hallo Thomas,

hast du schon mal warmstart oder forcegrub probiert?

VG, Thomas

92

Hallo @thomas

heute mal beides getestet - keine Änderung.

Viele Grüße
Thomas

93

Guten Morgen Thomas.

Ich fürchte, ich kann es nicht nachvollziehen. Ich habe

Kernel = vmlinuz.old
Initrd = initrd.img.old

als alternativen Kernel in die start.conf eingetragen und mit linuxmuster-import-devices in die grub configs übernommen. Danach mit

KernelOptions = quiet splash dhcpretry=5

und mit

KernelOptions = quiet splash dhcpretry=5 forcegrub warmstart=no

gebootet. Beide Male wurde korrekterweise der old-Kernel gebootet. :no_good_man:

VG, Thomas

94

könnte eine neue Version des Symptoms:

sein.
VG. Tobias

95

Hallo @thomas

per SSH auf dem Surface nachgeschaut - da stimmte die start.conf nicht überein. Also nochmal alles platt gemacht und neu synchronisiert.

Und tatsächlich geht es jetzt - an was auch immer es lag (Linbo-Version hatte ich eigentlich überprüft).

Noch etwas erfreuliches:

Nach https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup vorgegangen und auf dem Server den Surface-Kernel installiert und als Linbo-Kernel eingestellt. Et voila: Linbo kann nun auch auf Surface-Geräten per Touch bedient werden.

Feine Sache!

Danke und viele Grüße
Thomas

96

Hallo Thomas,
„Scotty wir haben ein Problem“…
Gestern habe ich das linbo-update auf 4.2.11 eingespielt und heute starten meine PCs nicht mehr.
Am PC folgendes ausgegeben - läuft noch unter 4.2.10 (auch bei boot per usb-stick mit linbo 4.2.11:
Interface etho: got 10.24.28.2.
/init.sh: /env: line 33: syntax error: unterminated quoted string
Not splitting minimal start.comf.
/inbo.sh: /env: line 33: syntax error: unterminated quoted string

Das kommt dann endlos…

Hast du eine Idee?

Gruß
Bertold

97

Hallo Bertold,

kann ich im Moment nicht nachvollziehen. Hier läuft das produktiv ohne Probleme. Gehe auf 4.2.10 zurück, ggf. mit der forced netboot Methode. Und schau mal, was auf dem Linboclient in /.env drinsteht.

VG, Thomas

98

Hallo Thomas,
danke für die schnelle Rückmeldung - es lag an mir…
Wir haben unsere sophos gegen eine opnsense ausgetauscht, dabei hat sich das default-gateway und der dns-forwarder geändert. Beim Anpassen habe ich wohl etwas (was ich leider nicht weiß was…) kaputt gemacht… - wahrscheinlich die Namensauflösung.
Jetzt geht es aber wieder.
Danke!

99

Hallo Bertold,

ok, gut. Was ich aber machen werde ist Lesefehler der /.env-Datei während des init-Prozesses abzufangen.

VG, Thomas

100

Tach,
4.2.11 crasht bei uns 50% der Rechner mit aelterer Hardware das Image beim Einspielen, „trace“-Meldungen verheissen nix Gutes. Keine Ahnung wieso, das muss beim Umkopieren aus dem Cache passieren.

Vermute da vertraegt sich Linbokernel 6.6.4 irgendwie nicht mit dem alten Mainboard?
Back to 4.2.10 und das tut wieder, zumindest testen wir das gerade. Ich werde erstmal keine Upgrades von Linbo mehr machen, es sei denn es gibt den postsync-Parameter bei linbo-remote :innocent:

Gruss Harry