ok, danke für die Klarstellung, so hatte ich es eingetragen.
hatte ich gemacht.
PXE-Boot war eingestellt (sollte aber auch mit HDD-Boot gehen, oder?)
Ich hatte auch kein reboot-Problem, sondern der Rechner hat sich beim Hardware initialisieren festgefressen. Modprobe-Optionen haben nichts gebracht.
Ich bin wieder zurück auf 2.3.26, dazu wollte ich update_linbofs wissen, das macht das Paket linuxmuster-linbo-common aber selbständig (ich hatte nur linuxmuster-linbo zurückgesetzt und mich gewundert, dass er kein fs geschrieben hat).
Das musste ich zum Glück nicht.
Was mich gewundert hat und weshalb ich in einen bösen Ausfall eines ganzen Raumes geschlittert bin:
Den ersten boot mit neuem Linbo hatten sie bis ins Ubuntu überstanden. Nur den zweiten nicht mehr. Komisch.
Wenn mal Zeit ist, setz ich mich dran.
Hat das Nachteile? Warum gibt es denn dann ein linbo64?
PXE-Boot war eingestellt (sollte aber auch mit HDD-Boot gehen, oder?)
ja, auch ein lokal bootendes linbo holt sich die updates vom Server.
Ich wollte bei dir nur sicher gehen, dass es daran nicht hängt (Auch
Antwort auf Wilfrieds Frage).
Was mich gewundert hat und weshalb ich in einen bösen Ausfall eines
ganzen Raumes geschlittert bin:
… vielelicht haben sie direkt durchgebootet und du hast nicht hingeschaut.
linbo funktioniert ja: nur sieht man keinen Linbobildschirm nur das
version 229 oder so.
Im Hintergrund läuft linbo aber und macht die Aufgaben, die es bekommt
(sync+start)
Es ist ja nur die Anzeige defekt.
Clients zum Verwenden von
32bit linbo zwingst.
Hat das Nachteile? Warum gibt es denn dann ein linbo64?
weil es Rechner mit mehr als 4GB Hauptspeicher gibt und die will man
auch beim sync verwenden.
Außerdem stellen wir seit Jahren alles auf 64bit um: warum nicht linbo.
Die Frage ist also eher: warum gibt es linbo32 … ich denke mal nur
wegen der beschnittenen Intel Prozessoren (wer hat ein Lenovo T60?)
nein. Die PCs hängen und stehen auch nach 6h im Bildschirm, auf dem aus - und | und / LINBO geschrieben steht, drunter, dass er die Hardware einrichtet (oder so ähnlich). dann geht nix mehr. Deshalb die Frage, ob es wo eine Liste von KernelOptions gibt, die ich probieren kann.
ich klinke mich hier noch einmal ein weil ich heute einen neuen Rechner mit einem AMD A6 Prozessor erhalten habe und ich beim einrichten dieses Rechners einige Erfahrungen gemacht habe, die sich mit dem decken was Max beschrieben hat.
1.Aufnahme des Rechners ins Netz
Eine Aufnahme des Rechners ins Netz über die Linbo Oberfläche war nicht möglich, da der Rechner beim ersten Start mit PXE mit einer Konfiguration Meldung nach dem Linbo stehenblieb, bei allen weiteren Starts wurde der Bildschirm schwarz, erhielt aber ein Signal vom PC.
Letztendlich musste ich die MAC Adresse und alle anderen Daten von Hand in die workstations Datei eintragen und den Rechner so aufnehmen. Ich habe den Rechner in eine Gruppe übernommen, in der ich die Kerneloption modprobe.blacklist=radeon eingetragen habe und die mit meinen älteren AMDs funktioniert.
2. Aufspielen des Betreibssystems
Trotz der Aufnahme des Rechners in eine Gruppe mit modprobe.blacklist=radeon war kein Zugriff auf die Linbo Gui möglich, beim ersten Start kam noch eine Meldung dass er mit modprobe.blacklist=radeon nichts anfangen kann um dann stehen zu bleiben, bei späteren Starts ging es einen Schritt weiter, der Bildschirm wurde schwarz.
Über linbo-ssh und linbo_wrapper konnte ich dann die Betriebssysteme installieren und starten.
3. Betrieb des Rechners
Starte ich den Rechner jetzt ganz normal, bleibt er mit schwarzem Bildschirm stehen, sehr selten wird die oben schon beschriebene Meldung zu modprobe.blacklist=radeon eingeblendet. Der in der start.conf eingetragene Autostart wird ignoriert, ein Start ist nur über linbo-remote oder linbo-ssh am Server möglich.
Fazit
Ich werde jetzt wohl erst einmal wie von Holger beschrieben auf 32bit Linbo wechseln, aber für die Rechneraufnahme ist das ja wohl nichts?
bei der Rechneraufnahme hast du natürlich recht: da müßte man mal
testen, wie „nichtradeonrechner“ auf den Blacklistparameter reagieren:
dann könnte man das dem defaultlinbo mitgeben.
Trotz der Aufnahme des Rechners in eine Gruppe mit
modprobe.blacklist=radeon war kein Zugriff auf die Linbo Gui möglich,
beim ersten Start kam noch eine Meldung dass er mit
modprobe.blacklist=radeon nichts anfangen kann um dann stehen zu
bleiben, bei späteren Starts ging es einen Schritt weiter, der
Bildschirm wurde schwarz.
… das ist seltsam: vor allem die Meldung, da der Parameter ja schon
bekannt ist: er bewirkt ja etwas bei den anderen Rechnern…
Zum Hergang möchte ich sagen: dass es Probleme mit Radeon GPUs mit linbo
2.3.30 gibt wurde im Betatest (durch mich) bemerkt: klar, wo ich doch
hauptsächlich AMD Rechner habe.
Der workaround wurde dann zusammen mit Thomas gefunden und durch mich
getestet.
Bei mir funktionieren alle Rechner mit AMD Chipsatzgrafik und
Prozessorgrafik mit dem modprobe.blacklist=radeon: auch A8 Prozessoren.
Dabei habe ich folgende A8 Prozessoren:
AMD A8-6600K Black Edition (vom Jahr 2014)
und:
AMD A6-6400K
von letztem Jahr.
Alle anderen Rechner haben 780G Chipsatzgrafik.
Von meinen Rechnern mit AMD Chipsatzgrafik funktionieren folgende mit modprobe.blacklist=radeon:
Athlon II X2 250 bzw. 280 mit RS780L (Radeon 3000) (aus dem Jahr 2013-14)
A4-6300 mit HD 8370D (aus dem Jahr 2015)
Der folgende Rechner funktioniert nur mit 32bit linbo:
A6-9500 Carrizo Radeon R5 (aus dem Jahr 2017)
Die älteren Intel I3 bzw. I5 aus den Jahren 2010-2012 mit Intel Chipsatzgrafik funktionieren direkt ohne Anpassungen der KernelOptions.
Ich habe alle diese Rechner in einer Hardware Gruppe. Verwende ich dabei 64bit linbo erscheint bei den Intel Rechnern noch die folgende Meldung (wie bei dem hängenden AMD):
Werte modprobe.blacklist=radeon aus
/init.sh: eval: line1: modprobe.blacklist=radeon: not found
der Start geht bei den Intels aber weiter, das scheint nicht zu stören.
ich habe auch nur AMD Rechner, prozessorseitig x2, x4 und fx4
Meistens 760G Chipsatz.
alles unproblematisch mit dem Kernelparameter:
modprobe.blacklist=radeon
Friedrich hat ja nur mit den sehr neuen AMDs Probleme.
Ich habe die Updates noch nicht eingespielt, weil ich mir keine Probleme
mit dem Linbo einhandeln will.
Ich meine, dass in meinen /var/linbo/boot/grub/.cfg kein
managed by linuxmuster.net <http://linuxmuster.net>
steht. Nicht, weil ich es entfernt hätte, sondern, weil ich seit Version
openML 4 migriert habe und das wohl nie reingeschrieben wurde.
… das kann nicht sein.
Bei Updates wurde da nichts „reingeschrieben“.
Seit linbo 2.3 verwenden wir kein pxelinuix mehr sondern grub2 per PXE
und da wurde beim ersten UPdate von linbo 2.2 auf linbo 2.3 die grub.cfg
Dateien angelegt… natürlich mit
# ### managed by linuxmuster.
Also: wenn du nie was gemacht hast, dann steht das da drin.
Was soll / muss ich nun vorbereitend tun, um upzudaten?
apt-get update
apt-get dist-upgrade
Dann in die start.conf der AMD Rechner hinter
KernelOptions
folgendes anfügen (zu allem was da schon steht):
modprobe.blacklist=radeon
Dann import_workstations
machen und Clients booten.
Dass die dann erstmal linbo booten und noch vor Erreichen der Grafischen
Oberfläche rebooten ist normal und gewollt.
also bei mir ist nicht der Bildschirm schwarz, sondern die Rechner hängen und rühren sich nicht mehr. Ich habe Gigabyte Boards.
ModelName F2A88XM-HD3P
BiosVersion F3a
Chipsatz AMD A88X.
gerade kann ich das neue Linbo nicht testen, da wir die PCs brauchen. Sobald ich dazu komme, schaue ich, wie ich die PCs mit dem neuen Linbo zum laufen kriege. Vielleicht tut es ja auch einfach ein USB-Linbo-Boot.
wir haben dieselbe Problematik mit AMD Grafikkarten und festgestellt das beim 64bit Linbo Kernel (v4.9.50) und den KMS (Kernel Mode Setting) Treibern bestimmte Firmware Dateien fehlen. Diese sind aber zwingend notwendig um die Grafik anzuzeigen. In dem Moment, wo das Treiber Modul geladen wird, bleibt die Grafik hängen. Linbo-ssh funktioniert trotzdem.
Wir haben mal testweise den Ordner /lib/firmware/radeon (ca. 7,4MB) und /lib/firmware/amdgpu (ca 14MB) aus einem aktuellen linux-firmware Paket in die Linbofs eingebunden und mit laufender Grafik starten können.
Gibt es vielleicht die Möglichkeit mehr Firmware Dateien in das offizielle linuxmuster-linbo Release einzubinden, oder wird die linbofs dann zu groß um sie schnell genug übers Netz zu laden.
Die diskutierten Lösungsansätze mit 32bit Kernel oder Kernel Option “modprobe.blacklist=radeon” funktionieren bei uns natürlich auch. Die Grafik wird aber dann erst in der Linbo Gui angesprochen.
wir haben dieselbe Problematik mit AMD Grafikkarten und festgestellt das
beim 64bit Linbo Kernel (v4.9.50) und den KMS (Kernel Mode Setting)
Treibern bestimmte Firmware Dateien fehlen. Diese sind aber zwingend
notwendig um die Grafik anzuzeigen. In dem Moment, wo das Treiber Modul
geladen wird, bleibt die Grafik hängen. Linbo-ssh funktioniert trotzdem.
Wir haben mal testweise den Ordner /lib/firmware/radeon (ca. 7,4MB) und
/lib/firmware/amdgpu (ca 14MB) aus einem aktuellen linux-firmware Paket
in die Linbofs eingebunden und mit laufender Grafik starten können.
Gibt es vielleicht die Möglichkeit mehr Firmware Dateien in das
offizielle linuxmuster-linbo Release einzubinden, oder wird die linbofs
dann zu groß um sie schnell genug übers Netz zu laden.
Super Analyse: ich schreib Thomas.
Die diskutierten Lösungsansätze mit 32bit Kernel oder Kernel Option
“modprobe.blacklist=radeon” funktionieren bei uns natürlich auch. Die
Grafik wird aber dann erst in der Linbo Gui angesprochen.
Thomas schlägt noch vor, dass man
nomodeset
als kernelparameter versuchen kann.
Die diskutierten Lösungsansätze mit 32bit Kernel oder Kernel Option
“modprobe.blacklist=radeon” funktionieren bei uns natürlich auch. Die
Grafik wird aber dann erst in der Linbo Gui angesprochen.
Was heißt, die Grafik wird aber dann erst in der Linbo Gui angesprochen.
bekomme ich dann vorher keine Ausgaben angezeigt?
Die diskutierten Lösungsansätze mit 32bit Kernel oder Kernel Option
“modprobe.blacklist=radeon” funktionieren bei uns natürlich auch. Die
Grafik wird aber dann erst in der Linbo Gui angesprochen.
Was heißt, die Grafik wird aber dann erst in der Linbo Gui angesprochen.
bekomme ich dann vorher keine Ausgaben angezeigt?
doch: bekommst du: aber nur Konsolenausgaben (Text).
Erst die GUI schaltet die GraKa in den grafischen Modus: und der läuft
nicht ohne weiteres.
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?