Linbo Neu+Start dauert "plötzlich" ewig

Hallo Steffen,
in deinen Logs steht dP******g! drinnen. Solltest du ändern.
Warum speichert Linbo das im Log eigentlich mit?

Du nutzt die Option noapic. Gibt es dafür einen Grund?
Hast du es auch schon mit acpi=off oder pcie_aspm=off versucht?

Viele Grüße
Christian

Hi!

Ich schau mal, wie ich ermöglichen kann, alternative Kernel zu verwenden.

VG, Thomas

Hallo Thomas,

das wäre super!
Wir haben heute auch nochmal etwas getestet (z.B. Update auf Linbo 4.2.2). Nicht so ausführlich wie Steffen aber auch bei uns gibt es nach wie vor ziemliche Probleme. Wir haben jedoch wie oben geschrieben, Gigabyte-NVMe-SSDs, so dass es nicht nur die Crucials zu betreffen scheint. Auf AMD- und Intel-Rechnern.
Neu+Start des Windows-Images, welches mit Linbo 4.0.x noch problemlos funktionierte und wenige Minuten dauerte (ca. 7min), dauert mit Linbo 4.1 und 4.2.2 nun fast anderthalb Stunden und bricht oft mit i/o-errors ab.

Viele Grüße,
Jochen

P.S.: Ralf nimmt mal ein Corpus Delicti mit nach Essen, vielleicht könnt Ihr Euch an dem mal abarbeiten :wink:

Hallo Steffen,

habe das noch gefunden: Solid state drive/NVMe - ArchWiki
Evtl. hilft dieser Kernelparameter:
nvme_core.default_ps_max_latency_us=0

VG, Thomas

1 „Gefällt mir“

Moin!

Testet mal den 5.15er-Kernel: Lmn 7.2 testing - #540 von thomas

VG, Thomas

1 „Gefällt mir“

Hallo Thomas,

vielen Dank für Deine Mühe!!! Wir werden morgen gleich testen und berichten.

Liebe Grüße,
Jochen

Hallo @thomas ,

vielen Dank für Dein Engagement und die neuen Linbo-Versionen!
Ich habe auf Linbo 4.2.6 upgedated und in der custom_kernel sowohl den legacy- als auch den longterm-Kernel ausprobiert.
Mit beiden ziehen nun alle HW-Klassen ein neues Image wieder mit >100MB/s! :grinning:

Leider synct die eine HW-Klasse nach wie vor so extrem langsam. :disappointed_relieved:
Weißt Du, welchen Kernel Linbo in der LMN 7.1 bzw. Linbo 4.1.x verwendet hat und wir diesen für Linbo einbauen können?

Auch den o.g. Kernel-Parameter haben wir getestet, bringt leider auch keine Änderung.

Vielen Dank und viele Grüße,
Jochen

Hallo Jochen,

in Linbo 4.1.36 wurde Kernel 6.5.3 verwendet. Dessen Konfiguration habe ich für den 6.6.1 in 4.2 übernommen und noch die WLAN-Treiber ergänzt. Ich kann die 6.5er-Konfiguration nochmal nach 6.6 migrieren, um auszuschließen, dass dabei irgendwas kaputt ging.
Ansonsten kannst du den 6.5er-Kernel aus Linbo 4.1.36 rauskopieren und über custom_kernel einbinden. WLAN ist dann halt nicht.

VG, Thomas

Hallo Thomas,
erst mal vielen Dank für Deinen super schnellen Support und … außerdem bist Du unser persönlicher Held :star_struck: … denn es scheint bei uns jetzt zu funktionieren.
Wir nutzen jetzt Kernel 5.15.138 Unsere neueste HW-Klasse (Dell Optiplex 5000) zeigt kein anderes Verhalten als mit den verschiedenen Kernel zuvor und funktionieren also einwandfrei. Die Problem HW-Klasse (Dell 3060 mit den Crucial NVMe) läuft jetzt durch. Das Entpacken des Images dauert zwar geringfügig länger als zuvor (also mit Linbo 4.0.24) aber für uns völlig in Ordnung. Die Fortschrittsanzeige läuft recht zügig bis 99% durch und bleibt da dann noch knapp 10 Minuten hängen. Für ein 22GB Image benötigen wir ca. 18 Minuten. Beim Kernel 6.1.62 ist das Verhalten ähnlich. Aber wie gesagt, für uns ein schöne Lösung unseres Problems.
Achja, die Kernelparameter sind auch weniger geworden. Die Realtek NIC läuft jetzt ohne das wir die r8169 blacklisten müssen. Der Kernelparameter „nvme_core.default_ps_max_latency_us=0“ hatte zuvor keine Besserung gebracht. Aber ein sehr Interessanter Artikel, den Du da im Netz gefunden hast.

Viele Grüße
Steffen

1 „Gefällt mir“

Hallo Steffen,

sehr gut! :grinning: Danke für die Rückmeldung.

VG, Thomas

Hallo Christian,
ne Woche um zu antworten… da muss ich schneller werden :smirk:
Passwort ist geändert, hatte ich aber auch nicht erwartet, dass ein Passwort in einem Log protokolliert wird.
Warum nutzen wir noapic??? Keine Ahnung, aber eine Vermutung.
Es ist eine gewachsene Struktur, irgend jemand hatte es mal eingetragen und haben es immer wieder übernommen ohne drüber nachzudenken.
Habe noapic mal in einer HW-Klasse entfernt. Beim Booten bekomme ich Warnmeldungen
platform eisa.0 cannot allocate resource for eisa slot 1
Das muss ich aber noch nachprüfen, ob das miteinander zusammen hängt, weil ich ein paar andere Änderungen auch noch gemacht habe.
Die anderen beiden Bootoptionen, welche Du erwähnt hattest habe ich nicht getestet. Mit der Lösung von Thomas, dass ich den Kernel jetzt selber auswählen kann, hat ja schon eine Lösung gebracht. Aber für die Ferien wäre das nochmal eine Option zum testen, wobei ich hier wenig Erfolg sehe.

Viele Grüße
Steffen

Moin!

Ich habe in meinen Linbologs kein Passwort gefunden. Bei welcher Aktion wurde das geloggt?
Bitte Issue erstellen.

VG Thomas

Guten Morgen,
ich erstelle gerade mit dem neuesten Linbo (Kernel 6.6.1) ein Image und das dauert gefuehlt ewig.
Der Konvertprozess ackert schon eine gute Weile, auf alle Faelle viel laenger als vorher:
qemu-img convert -p -c -f raw -O qcow2 /dev/nvme0n1p2 jam

Hat das was mit dem Thread hier zu tun? Werde nicht so ganz schlau daraus.
Hat der 6er-Kernel Probleme mit bestimmter Hardware? Scheint mir auch so bei unserem Mint, deshalb frag ich.

Ist da performancemaessig noch Verbesserung zu erwarten? Kernelexperimente sind nicht meine bevorzugte Freizeitbeschaeftigung. :slight_smile:

Gruss Harry

Hallo Harry,

kann ich hier nicht bestätigen. Unsere Rechner (Lenovo ThinkCentre M75q G2, Lenovo Thinkbook und alte Core i3 Möhren) laufen mit dem 6.6.1 wie geschnitten Brot. Die ThinkCentre kann ich echt empfehlen. Ich fürchte du kommst nicht darum herum die anderen Kernels auszuprobieren.

VG, Thomas

Hallo Thomas,

die Tests, die Ihr am WE mit unserem Desktop gemacht habt, haben nicht unser Problem widergespiegelt. Außer zwischendurch kurz mal mit 4.2.8 haben die Rechner immer gebooted und man konnte sie partitionieren. „Nur“ das Syncen bzw. Neu+Start dauerte extrem viel länger und führt bei WIndows in 90% der Fälle mit i/o-errors zu einem nicht funktionierenden Image.

Seit letzter Woche haben wir in einem DV-Raum nun ein Problem mit der Vertrauensstellung. Die Lösung war seither ein Neu+Start aber das funktioniert ja momentan nicht. Wir haben also ein massives Problem.

Ich hab gesehen, dass ich oben geschrieben habe, dass das Problem auch schon mit Linbo 4.1.36, also Kernel 6.5.3 unter LMN 7.2 auftrat. Kannst Du in die Glaskugel schauen und sagen, welches Linbo wir vor den Sommerferien / Upgrade auf LMN 7.2 wohl verwendet haben und was das für ein Kernel gewesen ist?
Und wie könnte ich an den rankommen, ohne eine komplette 7.1-Umgebung wieder aufsetzen zu müssen? Hast Du den evtl. noch irgendwo rumfahren und könntest ihn mir zur Verfügung stellen?

Vielen Dank und viele Grüße,
Jochen

Hallo Jochen,

hast du schon den 5.15er-legacy-Kernel probiert?

VG, Thomas

Hallo Thomas,

ja, den legacy und den longterm.

Viele Grüße,
Jochen

Hallo Jochen,

in Essen haben wir sämtliche mitgebrachte HW zum Laufen gekriegt. Sicher dass dein Image Ok ist? Die alten Linbopakete sind alle auf GitHub archiviert unter Releases. Einfach das passende installieren. Dann liegt das alles unter /var/cache/linuxmuster/linbo/linbofs64. Danach den Server wieder auf den zuvor gemachten Snapshot zurücksetzen.

VG Thomas

Hallo Thomas,

am Image hat sich nichts geändert seit LMN7.1.
Wir haben zur Sicherheit aber auch noch ein anderes Image einer anderen HW-Klasse probiert, das auf dieser funktioniert, auch mit diesem gibt es auf den Desktops das Problem.

Ihr hattet auf dem exone aber kein Windows ausprobiert, oder? Linbo-Boot und Partitionierung waren wie gesagt nicht das Problem. Auch der Download funktioniert (wieder) fix.
Tante Google findet irgendwas mit neuem ntfs Treiber ab Kernel 5.15. Kann unser Problem evtl. damit was zu tun haben?

Danke Dir, mal schauen, wann wir das testen können, ohne durch die Snapshoterei den laufenden Betrieb zu stören.

Viele Grüße,
Jochen

Kann ich nix dazu sagen. Ich habe mit ntfs3 bisher nur gute Erfahrungen gemacht.

VG, Thomas