Boot bleibt bei: ‚This LINBO client is in remote control mode.‘
Danach kompletter Freeze.
Keine Maus, keine Tastatur.
Keine nbw01_linbo.log.
Firmware-Test
Firmware über /etc/linuxmuster/linbo/firmware eingebunden. Danach
update-linbofs ausgeführt.
Neues Fehlerbild: - ip: SIOCSIFFLAGS: Invalid argument - netlink error:
Operation not supported - udhcpc: Network is down
Test Longterm
custom_kernel: KERNELPATH=„longterm“
Ergebnis: - GUI erscheint. - Nur noch drehender Kreis. - Keine
nbw01_linbo.log.
Netzwerk
Notebook erhält 10.0.211.34. UDP-Kommunikation zwischen Server und
Notebook ist im tcpdump sichtbar.
Getestete Kernelparameter
forcegrub
noefibootmgr
dhcpretry
usbcore.autosuspend=-1
nomodeset
iommu=soft
amd_iommu=off
Beobachtung
Alle anderen Geräte funktionieren mit Stable. Mit Longterm funktioniert
das EliteBook besser, dafür starten andere Geräte nicht korrekt.
Frage
Ist diese Hardwarekombination bekannt und gibt es einen Patch oder
Workaround?
Hat hier zufällig wer eine Lösung? oder Tipps was noch getestet werden kann.
auch ich hab 7.4 seit mehreren Wochen Produktiv im Einsatz.
Fehler wurden in den letztn 2 Wochen keine mehr gefunden.
Insofern würde auch ich sagen, dass ein Upgrade (vorher Backup ist immer eine gute Idee) problemlos möglich ist: auch in produktiven Umgebungen.
Ich muss auch ehrlich sagen, dass ich mit frühen upgrades auf die neue lmn Version weniger Probleme habe, als wenn man Jahre später dann von lmn 7.2 auf 7.3 oder eben erst in 2 Jahren von 7.3 auf 7.4 upgraded. Derartige Probleme haben wir relativ häufig in der Liste …
HP Elite Books funktioniert jetzt mit der neuen LMN 7.4
Eine Notebook Serie habe ich noch und zwar die Lenovo L16 Gen1 mit einem Intel Ultra 5, dieser starte in Linbo, lädt auch noch das Image aber dann bleibt er bei 0% stehen.
dmesg Meldung:
nvme nvme0: controller is down; will reset
I/O error, dev nvme0n1
und immer wieder:
controller is down
Heißt LINBO beginnt mit dem Zugriff auf die SSD und der NVMe-Controller setzt sich permanent zurück…
Kennt zufällig wer das Problem?
das kriegen wir hin. Lass mir die Ausgabe von lsmod unter Ubuntu 26.04 und die Ausgabe von dmesg auf der Linbokonsole eines betroffenen Clients zukommen. Dann schaue ich mal.
Das klingt nach einem klassischen NVMe-Power-Management-Problem, wie es bei sehr neuer Intel-Hardware (Core Ultra, Meteor/Arrow Lake) öfter auftritt: Der Controller geht während der I/O-Last in einen tiefen Autonomous-Power-State (APST) und kommt daraus nicht mehr sauber zurück → „controller is down; will reset“ in Dauerschleife. Das ist kein LINBO-Bug, sondern ein Kernel/Firmware-Verhalten, das über einen Kernel-Bootparameter abgeschaltet werden kann.
Sofort-Workaround (ohne Codeänderung) für die betroffene L16-Gen1-Gruppe in start.conf:
Das deaktiviert APST für alle NVMe-Controller beim LINBO-Boot. Danach linuxmuster-import-devices (bzw. den entsprechenden Server-Import) erneut laufen lassen, damit die grub.cfg der Gruppe neu geschrieben wird.
Falls das allein nicht reicht, zusätzlich pcie_aspm=off anhängen – das deckt Fälle ab, in denen der Reset über PCIe-ASPM statt NVMe-APST getriggert wird.
Evtl. hilft das ja schon.
Falls es auf dem Server eine Linbo-Clientlogdatei /var/log/linuxmuster/linbo/<hostname>_linbo.log gibt, poste mal die Ausgabe von
grep -i firmware <logdatei>
Könnte sein, dass noch eine Firmwaredatei benötigt wird.
ja das habe ich auch schon rausgefunden, jetzt habe ich einen 74min laufen lassen und er hat 24% geschafft, sprich er macht doch was aber es dauert ewig…
mit der neuen LMN 7.4