Ich probiers…
Naja, ein bissle schneller geht’s:
Allerdings versteh’ ich’s nicht ganz. Wenn der r8168 seine firmware mitbringt, sollte das nichts bringen?!?
Hi.
Mal noch ne andere Frage:
Ich habe in den sources von apt folgendes drin stehen:
deb [arch=amd64 signed-by=/usr/share/keyrings/linuxmuster.net.gpg] https://deb.linuxmuster.net/ lmn72 main
in lmn72.list
und
deb https://deb.linuxmuster.net/ lmn71 main
in lmn7.list
und das nach der Aktualisierung auf lmn 7.2 vor drei Wochen.
Jetzt habe ich Linbo 4.2.2-0, ohne Vorwarnung bekommen. Ist das noch testing? Bzw. bekomme ich das, weil lmn72 noch „testing“ ist automatisch?
Wäre nur interessant zu wissen. Noch haben wir Ferien und das lässt sich testen/beheben, wenn Linbo nicht täterätätäte.
VG, Tobias
Hallo Tobias,
ichhabe auch beide Quellen drin: lmn71 und lmn72
Das gehört wohl so.
linbo 4.2.0
hat kein Testing durchlaufen: THomas hat es direkt ins Repo gestellt.
Er nahm wohl an, dass die Änderungen nur gering seien und dass es zu
keinen Problemen kommen würde.
War leider nicht so.
Die Probleme wurden aber sehr rasant behoben.
LG
Holger
1 „Gefällt mir“
Hi Holger,
ok. Super, danke!
Tobias
Hallo Thomas,
ich habe mal auf dem Rechner getestet - und er die Cache-Partition immer noch nicht zuverlässig (so bei jedem 2. Boot halt).
Was die Netzwerkerkennung angeht, ist es jetzt natürlich etwas unschön, dass man bei unseren (vielen hundert) in-der-Regel-Offline-Clients ziemlich lange Linbos verzweifelten Versuchen beiwohnen muss, eine IP zu bekommen. Ist absehbar, ob die Netzwerkerkennung bald wiederkommt? Gibt es schon Ideen, die ich mal testen könnte?
Insgesamt habe ich ein wenig hin und her überlegt, wie man solche Offline-Clients grundsätzlich behandeln könnte, um den Regelfall „kein Netzwerk“ abzufangen, ohne auf Linbo zu verzichten (z.B. Kernel-Flag „offline“ - den bekommt man dann aber nciht mehr weg, GUI-„Connect“-Knopf - ist aber viel Aufwand, …). So richtig die zündende Idee habe ich noch nicht…
Viele Grüße
Thomas
Hallo Thomas,
Das ist wieder genauso wie es bei 4.1 war. Ich hatte im Zuge der Wlan-Implementierung eine Linkerkennung mit ethtool hinzugefügt, um die Anforderung einer IP-Adresse per udhcpc für eth0 zu überpringen, wenn kein Link da ist. Hat leider nicht funktioniert. Evtl. zu früh im Bootprozess, später funktioniert es ja. Wenn die Clients hauptsächlich linbo-offline benutzt werden, dann bietet sich doch ein vorgeschaltetes Grub-Menü an, das erst nach einem Timeout in Linbo bootet. Diese Option gibt es ja schon eine Weile.
Liegt wahrscheinlich am Gui, das stur immer die in der start.conf gefundene Cachepartition an linbo_cmd übergibt. In dem Fall benutzt linbo_mountcache den übergebenen Parameter und bestimmt nicht selbst anhand des Labels, welcher Gerätename gültig ist. Ich sehe 2 Lösungen:
- linbo_mountcache ignoriert übergebene Gerätenamen. Eher schlecht, da man evtl. mal auf der Linbokonsole eine abweichende Cachepartition mounten will und generell CLI-Parameter immer vorgegebene Werte überschreiben sollten.
- Das Gui benutzt einfach linbo_mountcache ohne Parameter, wenn es die Cachepartition mounten will.
Was meinst du @dorian ?
VG, Thomas
Noch ne Lösung: linbo_gui nutzt ja noch den 4.0-Kompatibilitätslayer linbo_cmd, das dann wiederum linbo_mountcache aufruft. Ich lasse einfach linbo_cmd den Parameter ignorieren. Passt!
VG, Thomas
Hallo Thomas,
ich habe das Gefühl, es dauert jetzt deutlich länger (z.B. „2. Versuch“) - aber mein Vergleich ist bei den Offline-Geräten ein älteres Linbo.
Das mit dem vorgeschalteten Grub-Menü kenne ich - aber Linbo ist eben das, woran sie gewöhnt sind und was sie auch nutzen sollen zur Wiederherstellung, etc… Ein zusätzliches Menü, das anders aussieht… wir haben auch nach 10 Jahren noch Nutzer, die erstaunt sind, dass der rote Knopf den Rechner repariert…
Ich probiere einfach ein wenig rum mit den hook-Skripten, vielleicht fällt mir ja etwas ein…
Danke und viele Grüße
Thomas
der fliegt im nächsten Release wieder raus, ist noch ein Testing-Überbleibsel.
VG, Thomas
Hallo Thomas,
wenn du mir alle Änderungen dokumentierst, passe ich die gui gerne dahingehend an.
VG,
Dorian
Hallo zusammen,
jetzt ist mir doch noch etwas recht gravierendes aufgefallen - vielleicht hat ja jemand eine Idee! Zunächst aufgefallen bei einem Lenovo T480, jetzt bei einem T470s, der bis vor kurzem problemlos lief:
- IP wird zugewiesen, Gruppe stimmt
- linbo64 wird geladen
- zurück in die Linbo-Konsole → „Starting version 249.11-0ubuntu3.10“
- ab dann wechselt der Bildschirm ein paar Mal zu schwarz und Textanzeige - irgendwann bleibt er schwarz
Von der Beobachtung würde ich sagen, dass da ein Grafikmodus zu initialisieren versucht wird, was scheitert. Aber was ist da anders? Der neuere Kernel?
Wir haben fast nur gebrauchte Lenovos - das ist also derzeit schlecht 
Viele Grüße
Thomas
Hallo Thomas,
ich hab das hier mit Lenovos getestet: da klappte es (nachdem das
Netzwerkproblem behoben war).
Es waren
Lenovo T540, T470 und Yoga L13
Hast du mal
nomodeset
versucht?
Normalerweise bei INtel Grakas nicht nötig … aber wer weiß …
LG
Holger
Hallo Holger,
nomodeset habe ich als erstes probiert.
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…
Rätselhaft! X1 Yogas funktionieren.
Viele Grüße
Thomas
Hallo Thomas,
gib ihnen mal einen etwas längeren dhcpretry Timeout (z.B. 8)
Und wenn das nicht hilft: vielleicht bekommt sich das frisch vom Netz
geladene linbo mit dem in der cachpartition in die Haare.
Mal den cache leeren …
LG
Holger
Hallo Holger,
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…
Hallo Dorian,
ich werde das bei Gelegenheit in linbo_cmd darstellen und kommentieren. Evtl. hilft das erstmal weiter.
VG, Thomas
Hallo zusammen,
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?
Ich teste weiter…
Viele Grüße
Thomas
1 „Gefällt mir“
Hallo Thomas,
2 Möglichkeiten:
- mit einem pre-hook-Skript die Datei etc/modules manipulieren, wenn der eigene Kernel bestimmte Module nicht hat, oder
- linux-generic-hwe-22.04-edge auf dem Server installieren und den Kernel mal einbinden.
VG, Thomas
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/*))"
VG, Thomas