doch: bekommst du: aber nur Konsolenausgaben (Text).
Erst die GUI schaltet die GraKa in den grafischen Modus: und der läuft
nicht ohne weiteres.
aber vor der Linbo-GUI kommt doch eh nur Text ?!?
Wichtig wäre halt, dass an jedem PC die Linbo-GUI weiterhin geht. Ich
habe noch immer nicht geupdated, auch wenn du meintest, bei meinen
(bislang ausschließlich) AMD Prozessoren und onboard Grafik sollte ich
mit „modprobe.blacklist=radeon“ keine Probleme bekommen.
doch: bekommst du: aber nur Konsolenausgaben (Text).
Erst die GUI schaltet die GraKa in den grafischen Modus: und der läuft
nicht ohne weiteres.
aber vor der Linbo-GUI kommt doch eh nur Text ?!?
Wichtig wäre halt, dass an jedem PC die Linbo-GUI weiterhin geht. Ich
habe noch immer nicht geupdated, auch wenn du meintest, bei meinen
(bislang ausschließlich) AMD Prozessoren und onboard Grafik sollte ich
mit “modprobe.blacklist=radeon” keine Probleme bekommen.
alle AMD die ich habe funktionieren ohne Probleme damit.
Es gibt bisher einen Nutzer dessen sehr neue Radeon APUs nicht mit dem
Switch laufen.
Falls die firmware in den linbo Kernel aufgenommen wird laufen alle
wieder ohne irgend welche Parameter.
nomodeset könnte auch bei allen helfen.
Also: wenn du nie was gemacht hast, dann steht das da drin.
ich habe mal nachgesehen. Die genaue Zeile heißt
Sollte also passen.
Dass die dann erstmal linbo booten und noch vor Erreichen der Grafischen
Oberfläche rebooten ist normal und gewollt.
Ich habe jetzt die Updates eingespielt. Da ich remote eh nicht sehen
kann, was die beim Booten anzeigen würden, warte ich einfach den Montag
ab. Eigentlich sollten (hoffentlich) alle Clients morgens wie gewohnt
per linbo-remote aufwachen, syncen und ins BS booten.
### managed by linuxmuster.net <http://linuxmuster.net>
Sollte also passen.
Dass die dann erstmal linbo booten und noch vor Erreichen der Grafischen
Oberfläche rebooten ist normal und gewollt.
Ich habe jetzt die Updates eingespielt. Da ich remote eh nicht sehen
kann, was die beim Booten anzeigen würden, warte ich einfach den Montag
ab. Eigentlich sollten (hoffentlich) alle Clients morgens wie gewohnt
per linbo-remote aufwachen, syncen und ins BS booten.
hast du den blacklist Parameter in die start.conf reingeschrieben?
ich habe bei allen PCs mit AMD-CPU in der start.conf bei KernelOptions „modprobe.blacklist=radeon“ hinzugefügt und dann import_workstations laufen lassen. Laut Ausgabe wurden die grub.cfg Dateien neu geschrieben.
Ich hoffe mal, dass am Montag alle Rechner aus linbo-remote booten.
ich habe bei allen PCs mit AMD-CPU in der start.conf bei KernelOptions
“modprobe.blacklist=radeon” hinzugefügt und dann import_workstations
laufen lassen. Laut Ausgabe wurden die grub.cfg Dateien neu geschrieben.
Ich hoffe mal, dass am Montag alle Rechner aus linbo-remote booten.
bedenke, dass du eine neue linbo64.fs hast: also booten die Clients,
installieren grub und machen einen reboot.
Du mußt also deine -w Zeit in linbo remote entsprechend anpassen.
Ich würde sagen: ca. 40 Sekunden mehr
bedenke, dass du eine neue linbo64.fs hast: also booten die Clients,
installieren grub und machen einen reboot.
Du mußt also deine -w Zeit in linbo remote entsprechend anpassen.
Ich würde sagen: ca. 40 Sekunden mehr
ich hab da imho eh schon eine recht lange Zeit eingestellt, da es mich
morgens ja nicht juckt, ob die erst mal untätig in Linbo stehen.
heute bin ich einmal dazu gekommen, den Vorschlag von Thomas nomodeset als Kernelparameter umzusetzen:
Alle meine AMDs funktionieren jetzt wieder problemlos mit linbo64, auch der ganz neue Rechner, der mit dem Parameter modprobe.blacklist =radeon nicht funktioniert hat.
Den Parameter modprobe.blacklist =radeon habe ich ganz herausgenommen.
Mit nomodeset ist der Start auch wieder „schöner“, da angezeigt wird dass etwas passiert, im anderen Fall blieb der Bildschirm relativ lange schwarz.
Mit nomodeset ist der Start auch wieder „schöner“, da angezeigt wird
dass etwas passiert, im anderen Fall blieb der Bildschirm relativ lange
schwarz.
das mit dem lange schwarzen Bildschirm habe ich heute auch festgestellt,
nachdem ich am WE endlich die Updates eingespielt habe.
Ich stelle dann auch mal auf nomodeset um.
Eine Sache ist mir aber noch immer nicht klar:
Wenn ich das richtig verstanden habe, braucht man den Kernelparameter,
da bei AMD-Rechnern sonst die grafische Linbo-Oberfläche nicht angezeigt
wird.
Was passiert dann, wenn ich einen neuen AMD-Rechner aufnehmen will, für
den es ja beim ersten Start per PXE noch gar keine start.conf und damit
keine Kernelparameter gibt?
Ich werde nämlich noch vor Fastnacht vor der Situation stehen, einen
AMD-Rechner im System testen zu müssen.
Bisher habe ich einfach per PXE gestartet und dann auf der
Linbo-Oberfläche den Rechner registriert, import_workstations,
start.conf angepasst, partitioniert, synchronisiert und geschaut, ob
auch Ubuntu startet.
Das Registrieren würde ja dann so nicht gehen. Klar, kann man die MAC
auslesen und den PC direkt in die workstations schreiben, aber wie komme
ich beim nackten Rechner am Schnellsten an die MAC?
Ich weiß grad nicht, ob die beim Start irgendwann angezeigt wird oder im
BIOS steht…
habe heute erst ge-updated. von 2.3.26 auf 2.3.36 (babo62-testing).
Habe bei alten PCs, genauer: den Displays von Samsung, die zusammen mit dieser seltsamer Monitoringlösung “Digitale Schimmel-Brot” angeschafft wurden.
“nomodeset” alleine hat nicht gereicht, ich habe noch ein import_workstations (und sicherheitshalber ein update-linbofs) hinterher gejagt, dann erst funktionierte es. Auch bei mir das Phänomen, dass der Rechner bei “Werte BOOT_IMAGE=/linbofs64 aus.” stehen.
Der Output von “starting version 229” kommt übrigens von systemd, welches einfach mal ein kernel.debug() raushaut, hardcoded.
Weil das “import_workstations” noch in der Doku fehlte, hab ich es ergänzt.
for the record: Selbst bei einer Grafikkarte “cirrus” in einem KVM-virtualisierten Client funktioniert LInBO nur nach Setzen von “nomodeset” und Aufruf von “import_workstations” anschließend.