Linbo hängt auf Lenovo M720s

Hallo,

so, meine nächste Baustelle.
Wir haben einige Lenovo M720s. Ein paar vom April, ein paar von letzte Woche. Einziger erkennbarer Unterschied: Alt: Samsung SSD, neu: Intel SSDPEKKF010T8L

Im BIOS ist alles exakt gleich eingestellt.
Die „alten“ Geräte (mit Samsung, vorher unter linuxmuster6.2 betrieben) booten Linbo 2.3.65 (linuxmuster7), die neuen bleiben bei „LINBO Initializing hardware …“ stehen.

UEFI und alle sonstigen „Secure“-Sachen sind aus. Wie gesagt, bei den älteren Geräten läuft es auch.

Ich habe mir einen linbo-USB-Stick erstellt (wieso gibt es in der WebUI unter Geräteverwaltung - Linbo rechts unten den Text „Download Linbo Boot“ ohne Funktion? Wenn das derzeit nicht tut, wäre doch eine kleine Hinweisseite auf den Download mit SCP hilfreich…), auf USB-Stick gezogen (mit der Startmedienerstellung von Ubuntu geht das nicht mehr - wenn ich linbo.iso öffnen will, bleibt das Dateifeld leer, mit anderen iso’s tuts. Musste dann unter Windoof Rufus nehmen), alle Menüpunkte (auch debug) durchprobiert, bleibt immer an der gleichen Stelle hängen.

Ich habe mit gparted von USB gebootet, eine Partitionstabelle und eine ext4-Partition auf der Disk erfolgreich angelegt, beim Neustart bleibt Linbo dennoch hängen.

Wie komme ich da weiter?

Grüße,
Stefan

Hallo Stefan,

Der Button war hinter einen transparenten div „versteckt“, und damit nicht klickbar.
Ich habe es korrigiert : Unhide linbo boot button. · linuxmuster/linuxmuster-webui7@4d50160 · GitHub

Gruß

Arnaud

Hallo,

OK, zunächst mal mein Fehler: Da war noch ne separate Grafikkarte eingebaut, die wir aus den alten Rechnern schon entfernt hatten (der Kreis hat die Rechner mit extra Grafik bestellt, wir wollten nur mit Onboard), Grafikkarte raus, Boot mit Onboard-Grafik und Linbo startet. Soweit, so gut.

Nächstes Problem:
Ubuntu startet nicht.
Ich hab verschiedene Kernelparameter durchprobiert, bei acpi=off kommt er bis zum Anmeldebildschirm, dort funktionieren aber weder Maus noch Tastatur… Bei allen anderen Parametern bleibt er irgendwo vorher stehen, bei irqpoll z.B. beim Mauszeiger auf schwarzem Hintergrund.

Jetzt habe ich bei weggeklicktem Plymouth-Bootscreen beim Booten folgende Zeilen gesehen:
Activated swap /dev/nvme0n1p3
A start Job is running for /dev/sda3

In der fstab habe ich die sda’s rausgepatcht, aber irgendwo steht offenbar noch das sda3 drin… Wie finde ich denn das jetzt wieder?

Grüße,
Stefan

Hallo Stefan,

versuche es doch mal mit:

sudo grep -rnw '/etc/' -e 'dev/sda'

Beste Grüße

Thorsten

Hallo,

in /run/systemd/generator habe ich noch die Datei dev-sda3.swap gefunden.

Bloß was mache ich mit der Datei? Ich würde ja auf dem nvme-System mal rumspielen oder ins Log schauen, aber dazu müsste das Teil ja mal gescheit booten…

Grüße,
Stefan

Hallo,

mal wieder gefrustet… Bin noch nie in den Sommerurlaub, wenn in der Schule noch nix tut, aber dieses Jahr…

17 werksneue Lenovo M720s, am letzten Schultag ausgepackt. Rechneraufnahme lief. Syncen auch.

  • Aber Rechner 1 bleibt an unterschiedlichen Stellen beim Booten von Ubuntu 20.04 hängen.
  • Rechner 2 (gleiche Bios-Version, gleiche Ausstattung, gleiche Bios-Einstellungen - bin sie Menü für Menü mit einem Kollegen durchgegangen) startet. Spannenderweise mit NVME-SSD, obwohl in der fstab noch sda drinstand. Login auch als User möglich, Rechner läuft längere Zeit stabil. Fstab korrigiert, cloop erstellt, auf Rechner 3 gesynct.
  • Rechner 3 (wieder alles gleich eingestellt) bootet das neue Cloop, wenn man schnell ist, kann man sich als linuxadmin einloggen, dann bleibt er hängen. Wenn man etwas wartet, bleibt er noch im Login-Bildschirm hängen (Tastatur+Maus eingefroren).
  • Rechner 4 siehe Rechner 3.
  • Rechner 1 bleibt auch mit dem neuen Cloop schon beim Booten hängen.

Warum wurde die fstab nicht per postsync gepatcht? Er nimmt immer die fstab aus /srv/linuxclient/ubuntu20/… und nicht die aus /srv/linuxclient/nvme_ubuntu20/…, obwohl die Rechner in der Gruppe nvme_ubuntu20 sind. Warum auch immer.

Äußerst uneinheitlich und äußerst unbefriedigend.

Nehm jetzt mindestens eine Woche rechnerfrei, vielleicht haben die Computer sich (und vor allem ich mich) danach beruhigt und machen das, was sie sollen…

Aber als Anmerkung:
Ich habe als Schulserver Arktur, die alte PaedML Linux und linuxmuster 6 erlebt, aber solche vielfältigen und hartnäckigen Probleme wie jetzt mit der linuxmuster 7, hatte ich noch nie!

Grüße,
Stefan

Hallo Stefan,

geht mir, nachdem wir von 3 verschiedenen Testrechnern nur einen mit Müh und Not zum Laufen bekommen haben, ähnlich!
Wobei ich v.a. die neuen „BIOSe“ bzw. UEFIs dafür verantwortlich mache und v.a. Lenovo scheint sich hier als Hersteller (leider!) auch nicht mit Ruhm zu bekleckern.
Klar, unter Win (oder Linux) allein laufen die wohl, von daher kann man schon auf den Gedanken kommen, dass es an LMNv7 liegt.
Leider sehe ich hier einen Boomerang auf uns zukommen, wenn ich mich erinnere, wie wir seinerzeit hämisch REMBO belächelt haben, weil die mit neueren Clients nicht mehr konnten. Jetzt sind wir selbst die Gelackmeierten…

Nachdem ich im Herbst nach ähnlichen Erfahrungen, wochenlangen Tests, Hilfen aus dem Forum und unter Ausnutzung aller Tricks (legacy boot, boot order lock etc pp) dann doch noch die bereits angeschafften Lenovo E490 zum Laufen bekommen habe, habe ich daraus gelernt und lass mir jetzt vorab immer ein Testgerät schicken (auch wenn Deine Erfahrung zeigt, dass eines vielleicht gar nicht genügt…) aber das macht die Sache natürlich auch viel aufwendiger: Testgeräte beschaffen, testen, wieder zurückschicken und der Schulleitung erklären, warum die Geräte alle nicht funktionieren („Windows lief doch im Auslieferungszustand, das muss an Eurer Lösung liegen…!“ - so Gott sei Dank noch nie hören müssen aber das könnte irgendwann kommen).

Viele Grüße,
Jochen

Hallo Jochen,

Testgeräte bekommen wir seit Jahren gestellt, steht so in der Ausschreibung des Schulträgers für die Kreisschulen. Bringt leider nix, wenn die Geräte noch von mir letztes Jahr mit lml6.2 und Ubuntu16 getestet wurden und sich unter lml7 und Ubuntu20 anders verhalten. Außerdem haben die aktuellen Geräte eine andere Bios-Revision als die vorherige Lieferung… Die M720 sind von Lenovo abgekündigt, die nächsten Testgeräte werden bald eintrudeln, und testen kostet auch Zeit…

Grüße,
Stefan

Hi Stefan,

I love it…

Oh ja, wem sagst Du das! Bei aller Freude über neue, performante(re) Hardware hab ich auf das ewige Testen nach den ganzen (mehrheitlich) negativen Erfahrungen so was von keinen Bock mehr!

Viele Grüße,
Jochen

Hallo,

die Lenovo sind teuflisch!

Ungefähr die Hälfte unserer Lenovo booten Ubuntu 20.04 aus Linbo heraus korrekt. Die andere Hälfte nicht. Egal ob aus der Lieferung von März oder von Juli. manchmal bleiben die Clients direkt beim Ubuntu-Boot-Bildschirm stecken, manchmal beim Anmelde-Bildschirm, wenn man schnell ist, manchmal auch erst nach dem erfolgreichen Anmelden. Die andere Hälfte läuft über Stunden stabil.

Soweit, so unlogisch.

Weiter: Einige der korrekt arbeitenden Clients haben eine um eine Stunde vorgehende Systemzeit. Logischerweise bekommen User dann kein Home_auf_server, keine Firefox-Bookmarks, kein SSO.

Ein Schritt weiter:
In der Start.conf der Gruppe im Ubuntu-Abschnitt
Append = ro splash acpi=off
eingetragen.
Jetzt booten alle Clients zuverlässig, die M720s finden dann allerdings einen zweiten, nicht vorhandenen Bildschirm (unsere M720q nicht) - weniger schlimm - und sie fahren nicht runter (nur nach längerem Druck auf die Power-Taste, M720s wie M720q) - schlimm, weil die Schüler und Kollegen das garantiert vergessen.
Und vor allem:
Die Systemzeit geht jetzt auf allen Clients um 2 Stunden vor. Im Bios ist sie korrekt, in Linbo ist sie korrekt, unter Ubuntu falsch.
Wenn ich die Systemzeit mit date und hwclock --systohc korrigiere, kann ich mich als User korrekt anmelden, Homes da usw.
Wenn ich dann neu starte (tut nur nach Druck auf Power-Taste…) - bleibt die Systemzeit zu meinem Erstaunen korrekt! Muss man nicht verstehen, oder?

Ich habe alles mögliche an Bootparametern ausprobiert (noapic, nolapic, irqpoll, acpi=noirq, acpi=oldboot…), nur acpi=off scheint zu helfen, aber die Nebenwirkungen gefallen mir nicht!

Grüße,
Stefan

Hallo,

hab heute nochmal getestet:

  • acpi=off
  • Kernel auf einem der Rechner neu installiert
  • acpi=off gelöscht
  • Neustart - bleibt hängen (Enttäuschung)
  • Neustart - bootet erfolgreich, Login möglich (Hoffnung)
  • Neustart - bootet erfolgreich, Login möglich (mehr Hoffnung)
  • Neustart - bleibt hängen (Frust)

Auf einem Rechner, der bisher immer sehr früh beim Booten hängenblieb:

  • Im BIOS C-States des Prozessors auf minimal geschaltet (nur C1)
  • Neustart (ohne ahci=off): Rechner bootet, Login möglich
  • Neustart: bleibt hängen
  • Neustart: bleibt hängen
  • Neustart: Rechner bootet, Login möglich (manchmal stürzt er aber auch direkt nach dem Login ab)
  • Mit anderen BIOS-Einstellungen rumgespielt, ändert sich aber nichts.

Dieses „mal tut’s, mal nicht“ macht mich wahnsinnig!

Ach so, Booten nur über Grub ohne Linbo habe ich auch schon erfolglos probiert…

Dass die Rechner mit ahci=off nicht korrekt runterfahren, wird im Normalbetrieb echt zum Problem werden, ich will das irgendwie lösen.
Vor allem: Es hat ja bisher mit linuxmuster 6.2 sowie einem Ubuntu 16.04 mit HWE-Stack ja mal ohne ahci=off zuverlässig funktioniert… Macht der 20.04er Kernel (5.4) irgendwas anders?

Grüße,
Stefan

Hallo Stefan,

Die Systemzeit geht jetzt auf allen Clients um 2 Stunden vor. Im Bios
ist sie korrekt, in Linbo ist sie korrekt, unter Ubuntu falsch.
Wenn ich die Systemzeit mit date und hwclock --systohc korrigiere, kann
ich mich als User korrekt anmelden, Homes da usw.
Wenn ich dann neu starte (tut nur nach Druck auf Power-Taste…) - bleibt
die Systemzeit zu meinem Erstaunen korrekt! Muss man nicht verstehen, oder?

wenn ubuntu die Zeit synct, dann trägt es das auch ins BIOS (wenn das so
eingestellt ist) ein … dann stimmt sie ab dem Zeitpunkt: auch nach reboots.

Schau mal hier hin:

LG

Holger

Hallo,

Heureka!!!

Mannmannmannmann, das war eine schwere Geburt und hat mich viele Stunden gekostet, aber jetzt habe ich die Lösung! Ich kam drauf, als ich mal testhalber als Bootparameter quiet eingeschaltet habe, da erschien dann als einzige Meldung ein Fehler mit „sof audio pci“ irgendwas. Eine kurze Internetrecherche brachte den Kernel-Parameter
snd_hda_intel.dmic_detect=0
zutage, und der hilft tatsächlich, alle Rechner fahren zuverlässig hoch, Login ohne Absturz möglich, ohne das blöde acpi=off fahren sie auch wieder runter und es gibt kein zweites, rätselhaftes 13"-Display, keine hängenden Tastendrücke usw.

Also nochmal zusammengefasst:
In der start.conf der Gruppe steht jetzt im Ubuntu-Abschnitt die Zeile:
Append = ro splash snd_hda_intel.dmic_detect=0

Damit laufen unsere Lenovo M720s und M720q mit Ubuntu 20.04 problemlos.

Boah, damit fallen mir ein paar Zentner von den Schultern.
Zeit, mir die nächste Last aufzuladen: Die blöden Smartboard-Rechner warten…
Das mit der Zeit schiebe ich etwas nach hinten…

Grüße,
Stefan

1 „Gefällt mir“

Hallo Stefan,

Mannmannmannmann, das war eine schwere Geburt und hat mich viele Stunden
gekostet, aber jetzt habe ich die Lösung! Ich kam drauf, als ich mal
testhalber als Bootparameter quiet eingeschaltet habe, da erschien dann
als einzige Meldung ein Fehler mit „sof audio pci“ irgendwas. Eine kurze
Internetrecherche brachte den Kernel-Parameter

snd_hda_intel.dmic_detect=0|

… es ist so schön, wenn der Schmerz nach läßt :slight_smile:

LG

Holger