Was heißt das genau?
VG, Thomas
das heißt: in der start.conf steht autostart=yes und default=sync. Das funktioniert auch perfekt unter 2.3.x. Beim neuen Linbo wird das nicht „abgearbeitet“, d.h. der Rechner bootet per pxe, dann kommt der schwarze Bildschirm, Linbo steht und es geht nicht weiter.
Man kann sich per linbo-ssh einloggen und per linbo_wrapper die Befehle absetzen, was funktioniert. Ebenfalls funktioniert linbo-remote mit -c vom Server aus, wenn der Client in Linbo steht. Ein linbo-remote mit -p vor dem Boot des Clients auf dem Server abgesetzt bewirkt nichts, daher vermute ich eben, dass keine Startkonfiguration abgearbeitet wird.
Also mal davon abgesehen, dass es keine GUI gibt booten die Rechner nicht.
Ich habe jetzt 2 Stunden rumprobiert mit verschiedensten Kerneloptionen, mit neuen grub-cfg’s neuen start.confs und was mir noch so einfiel aber die Rechner booten halt einfach nicht aus Linbo weiter, außer eben manuell wie oben beschrieben.
Zurück auf linbo 2.3.x und alles funktioniert!?
VG Dominik
Ich hab beide Hardwareklassen nun mit Hilfe der grub.cfg zum laufen bekommen.
Dort in /srv/linbo/boot/grub/hardwareklasse.cfg habe ich set default=1
set timeout=3 eingetragen.
Alle Rechner booten somit.
Grüße Ralf
Ok, danke. Der Autostart geht nicht, weil die Gui nicht startet. Da müssen wir Kernelparameter finden.
Evtl. erfahren wir was von dmsg auf der linbo-ssh Konsole.
VG, Thomas
Das ist interessant. Du hast das Grubmenü eingeschaltet. Damit wird der Grafikmodus initialisiert.
VG, Thomas
Hallo zusammen,
im aktuellen linbo bzw. dem Kernel fehlt das Framebuffer Device /dev/fb0. Ich könnte mir vorstellen, daß das der Grund ist, wieso die GUI nicht startet.
EDIT: Im älteren linbo ist das Framebuffer Device vorhanden
Viele Grüße
Klaus
Danke für den Hinweis. Sieht so aus als ob der Framebuffer Treiber nicht automatisch geladen wird. Mir ist das nicht aufgefallen, da ich immer das Grubemenü aktiviert habe.
VG, Thomas
Hallo Thomas,
der Framebuffer Treiber ist im alten Kernel fest drinnen, also nicht als Modul.
Danke für’s neu Bauen und viele Grüße
Klaus
Ja, beim 5er Kernel habe ich fb wohl als Modul konfiguriert.
VG, Thomas
Eigentlich nicht:
~ # cat /lib/modules/$(uname -r)/modules.builtin |grep fb.ko
kernel/drivers/video/fbdev/core/fb.ko
Das Device ist aber trotzdem nicht da.
Ok, ist doch fest im Kernel.
Aber ich kann das hier mit 2.4.1 nicht nachvollziehen.
- Die mit -p linbo-remote übergebenen Befehle werden brav beim Boot ausgeführt.
- Bei meinen Clients wird das Framebuffer-Device auch ohne vorgeschaltetes Grubmenü initialisiert.
Ich denke, dass ein adäquater Kernelparameter weiterhilft.
VG, Thomas
OK habe schon einiges versucht…es ist aber schon seltsam, dass wirklich kein einziger Rechner bei mir funktioniert…wie gesagt…Intel…AMD der letzten 0 bis 10 Jahre. Die Intel Kisten booten zumindest überhaupt…die AMD Kisten nur mit nomodeset…
VG Dominik
Hallo Thomas,
ich kann den Fehler mit einer Virtualbox Testinstallation forcieren.
Bei Verwendung des Virtualbox Standard Video Treibers für die VM, also VBoxSVGA wird das Framebuffer Device nicht erstellt und der Bildschirm bleibt schwarz.
Bei Verwendung von VMSVGA funktioniert alles und das Framebuffer Device ist da.
Wahrscheinlich fehlt im aktuellen Kernel noch eine oder mehrere Config Optionen bzgl. Framebuffer. Evtl. könntest Du die Konfigurationen ja daraufhin vergleichen?
Viele Grüße
Klaus
Hallo Klaus,
ich habe die 4er config mit make olddefconfig übernommen, es sollte also alles gleich sein. Allerdings sehe ich im diff, dass im 5er CONFIG_FB_BACKLIGHT=m ist, vorher war es =y. Die Option lässt sich aber mit make menuconfig nicht ändern, bzw. wird gar nicht angeboten.
Testweise kann man mal das Laden des Moduls mit dem Kernelparameter loadmodules=generic_bl erzwingen. Evtl. bringt das ja was.
VG, Thomas
Hallo Thomas,
loadmodules=generic_bl zu setzen bringt leider nichts.
In der 4er bekomme ich beim Booten des Clients im dmesg Log:
vesafb: mode is 800x600x16, linelength=1600, pages=0
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: framebuffer at 0xe0000000, mapped to 0x00000000fd7d0623, using 960k, total 960k
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer deviceIn der 5er nichts dergleichen. Auch wenn ich das forciere mit video=vesafb ändert sich nichts.
Es muß also irgendeine Option im Kernel sein, welche nicht mehr aktiv ist. Evtl. wurde auch im 5er etwas aufgeteilt. Vielleicht könntest Du ja alle Optionen in der Kernel Config setzen bzgl „Console display driver support“, „Frame buffer Devices“, " Display Interface Bridges", „Display Engine Configuration“. Oder mal mit einer neuen Default Konfiguration starten?
Viele Grüße
Klaus
Hallo Klaus,
Bei meinen Clients, die seit 11.12.2020 produktiv mit dieser Linbo-Version laufen, sehe ich auch keine vesafb-Meldungen und die Grafikausgabe ist trotzdem da. Das kann nicht das Problem sein.
Wie gesagt, bzgl. Framebuffer hat der 5er dieselben Optionen gesetzt wie der 4er, Ausnahme Backlight.
Welche Grafik-Hardware haben die Clients verbaut? Welche Module sind unterm 4er geladen, welche unterm 5er?
Um ins Blaue hinein Test-Pakete mit verschiedenen Kerneln zu bauen fehlt mir schlichtweg die Zeit.
VG, Thomas
Evtl. läuft ja die neue Gui mit dieser HW.
VG, Thomas
Das geht natürlich auch nicht, wenn kein fb device da ist. Aber ich werde im nächsten Release testweise mal die Framebuffer-Konfiguration des Ubuntu-Kernels übernehmen.
VG, Thomas
Moin moin!
Es gibt jetzt eine Version 2.4.1-1 mit der vom Ubuntu-Kernel übernommenen Framebuffer-Konfiguration.
VG, Thomas
Hi @thomas,
läuft…vielen Dank! Alle Rechner funktionieren wieder wie zuvor. Es gibt beim Booten von Linbo aber folgende Fehlermeldung:
Ich meine auch, dass in dem Stadium vom Linboboot eigentlich eine Konsole mit Splashscreen zu sehen sein sollte…oder?
VG, Dominik