Kein Bild an der UCS-Konsole => Anmeldung nicht möglich

Hallo zusammen,

mein Server läuft als DC Master in der Version 3.1.-1 inkl. neuester Aktualisierungen. Zur Vorbereitung des Updates auf 3.2-0 wollte ich lokal an der Konsole ein Backup ziehen. Am angeschlossenen Monitor zeigt sich während des Bootvorgangs folgendes Bild:

Der Splash-Screen von Univention startet, das Logo dreht sich, nach ca. 3sec wird der Bildschirm schwarz und der Monitor meldet “Kein Signal”. Der Bootvorgang wird korrekt ausgeführt und der Server läuft einwandfrei. Zugriff über das Webinterface oder ssh ist einwandfrei möglich. EIn Versuch im Recovery-Modus zu booten ergibt das gleiche Ergebnis. In der Vergangenheit hatte die Anzeige natürlich einmal normal funktioniert. An der Hardware wurden keine Veränderungen vorgenommen. Alle Konfigurationen und Aktualisierungen erledige ich sonst von einem anderen Rechner aus über das Web-Interface der UMC. Ich kann daher nicht sagen wann oder in welchem Zusammenhang dieser Fehler aufgetreten ist. EIn anderer Monitor ergibt das gleiche Ergebnis.

Liegt hier evtl. ein Problem mit dem Grafikkartentreiber vor? Wo kann ich ansetzen?

lspci liefert:

00:00.0 Host bridge: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09)

Vielen Dank im Voraus.

Gruß
Uwe

Hallo,

Als das Anmelden an der Konsole noch funktionierte, hatten Sie da einen anderen Bildschirm dran?
Wenn Sie sich als root per ssh anmelden und eingeben:

dmesg | grep -Ei 'vga|console|frame'

findet man da vielleicht schon einen Hinweis?

viele Grüße
Frank Greif

Hallo Frank,

nein, ein anderer Bildschirm war vorher nicht angeschlossen. Wie erwähnt habe ich jetzt nach auftreten des Fehlers mit einem weiteren Monitor das gleiche Ergebnis erhalten.

dmesg | grep -Ei ‘vga|console|frame’ ergibt:

[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-ucs31-amd64 root=UUID=745b1ecb-0fd2-42b7-b3cf-32afcfa8842d ro quiet loglevel=0 vga=788 splash
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-ucs31-amd64 root=UUID=745b1ecb-0fd2-42b7-b3cf-32afcfa8842d ro quiet loglevel=0 vga=788 splash
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000122] Security Framework initialized
[    0.608638] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.608655] vgaarb: loaded
[    0.608658] vgaarb: bridge control possible 0000:00:02.0
[    1.479991] vesafb: framebuffer at 0xcf800000, mapped to 0xffffc90005100000, using 960k, total 960k
[    1.487802] Console: switching to colour frame buffer device 100x37
[    1.495347] fb0: VESA VGA frame buffer device

Mit diesen Zeilen kann ich nicht wirklich viel anfangen. Ist hierin etwas zu erkennen?

Gruß
Uwe

Hallo,

die Ausgaben sind exakt die gleichen wie bei meiner Testmaschine, also ich sehe hier nichts auffälliges. Ich würde im Grub-Menü mal probieren:
[ul]
[li] Taste c drücken, man kommt in einen Kommandomodus.[/li]
[li] eingeben set paging=1 (und Enter drücken) dadurch werden lange Ausgaben pro Bildschirmhöhe angehalten (wie ‘more’)[/li]
[li] eingeben vbeinfo dort listet es, ob im Bios die “Vesa Bios Extensions” vorhanden sind, welche Bildschirmmodi sie anbieten, und die allerletzte Zeile sagt, welcher Modus momentan in Benutzung ist.[/li][/ul]

So, nun müßte man sich einen Modus aussuchen, den die VBE anbietet, und versuchen ihn einzustellen. Die Mathematik ist etwas kryptisch: der Hex-Wert (z.B. 0x101 für 640x480x8(packed)) muß um hex 0x200 (dez. 512) erhöht und dann in dezimal umgerechnet werden. Wenn man irgendwo eine Linux-Shell zur Verfügung hat, kann man das rechnen lassen:

user@hostname ~ $ echo $((0x101+512)) 769
und diese Zahl muß dann in die Kernel-Kommandozeile als

vga=769

eingetragen werden. Man macht das durch folgende Schritte:
[ul]
[li] Taste ESC drücken, man kommt zurück ins Grub-Menü.[/li]
[li] Taste e drücken, man kommt in einen Modus, in dem man die aktuellen Grub-Kommandos (für diesen einen Systemstart) ändern kann.[/li]
[li] dort die betreffende Zahl an das vga=… Argument schreiben[/li]
[li] Ctrl-X drücken, es bootet sofort mit dieser Einstellung.[/li]
[li] Finger kreuzen und Atem anhalten ;-)[/li][/ul]

Kann sein, man muß diese Prozedur mehrmals mit unterschiedlichen Modi versuchen. Es gibt auch einen Befehl, mit dem man bereits im Grub ohne das System zu starten einen VBE-Modus testen kann, allerdings hat man da auch immer nur einen Versuch und muß mit Ctrl-Alt-Del den Computer neu starten, um wieder ins Grub-Menü zu kommen. Dies funktioniert so:
[ul]
[li] in Kommandomodus gehen (mit c, oder man ist schon drin)[/li]
[li] set vbe_mode=0x101 (der Modus kann hier direkt in Hex angegeben werden, so wie er von vbeinfo gelistet wird)[/li]
[li] eingeben videotest (und Enter drücken). Bildschirm wird schwarz. Ein weiteres Mal Enter, dann sollte der Bildschirm auf den betreffenden Modus umschalten und ein Testbild mit Rechtecken, Farben und Unicode-Zeichen anzeigen.[/li]
[li] danach kann man nur Ctrl-Alt-Del drücken, um ins Grub-Menü zurückzugelangen.[/li][/ul]

Nun möchte ich erst mal wissen, ob es sich damit schon behebt… wenn der Bildschirm selbst bei Modi schwarz bleibt, die eigentlich auf absolut jedem Monitor funktionieren müßten -> vielleicht hat die VGA mehrere Ausgänge (VGA, DVI, HDMI, DisplayPort oder was weiß ich) und die Ausgabe erscheint an einem Ausgang, wo nichts angeschlossen ist?

viele Grüße
Frank Greif.

Hallo Frank,

die Hinweise habe ich inzwischen einmal ausprobiert.

vbeinfo ergibt die Liste mit möglichen Auflösungen von denen ich verschiedene ausprobiert habe. In der UCR war die Variable /grub/vga mit 788 eingestellt (Auflösung=800x600x16). Diese Zahl sowie 773 für eine 1024x768x8-Auflösung und die 769 für die kleinste mögliche Auflösung mit 640x480x8 liefern bei Eintrag in die Kernel-Kommandozeile alle das gleiche Ergebnis wie zuvor.

Interessant: vbeinfo meldet am Ende der Liste “Configured VBE mode (vbe_mode) = 0x101”, der Monitor behauptet aber gleichzeitig er würde 800x600 anzeigen.

Mit der zweiten beschriebenen Methode habe ich ein seltsames Ergebnis. Nach der Eingabe von set vbe_mode=0xXXX und videotest bekomme ich bei allen getesteten Modi das gleiche Ergebnis: der Bildschirm wird zunächst schwarz, der Monitor meldet dann “Videofrequenz zu hoch”, nach dem zweiten Enter bekomme ich dann nur noch einen blinkenden Cursor in der oberen linken Ecke angezeigt, der Rechner zeigt keine Reaktion mehr. Dies leider auch bei der kleinsten möglichen Auflösung 0x101 = 640x480x8.

Die VGA hat in der Tat zwei Ausgänge: VGA und HDMI. Wie könnte man denn prüfen ob evtl. ab einem bestimmten Zeitpunkt während des Bootens auf den HDMI-Ausgang umgeschaltet wird?

Gruß
Uwe

Hallo Uwe,

das sieht aus, als würde KMS (Kernel Mode Setting) hier nicht funktionieren. Das ist nicht das, was man landläufig “Grafiktreiber” nennt, sondern eine Kernel-Komponente, die bereits sehr früh beim Booten in den besten verfügbaren Grafikmodus umschaltet und dann darauf mit Hilfe der “Framebuffer Console” die Textkonsole darstellt.

Die Suchmaschine meiner Wahl hat mir zu diesem Thema u.a. den folgenden Link geliefert: distro.ibiblio.org/fatdog/web/faqs/screen.html Dort wird zwar beschrieben, daß das eigentlich für Intel Grafikkarten funktionieren soll, aber man weiß ja nie. Ich würde die dortigen Empfehlungen einfach mal durchprobieren:

[ul]
[li] den Parameter nomodeset zur Kernel-Kommandozeile dazufügen, dann wird KMS nicht benutzt, und der Kernel sollte dann die Vesa Konsole statt des Framebuffers für die Darstellung der Textkonsolen benutzen.[/li]
[li] oder eben mit dem video=… Parameter experimentieren, ob man damit erreichen kann, daß der Bildschirm nicht mit einer zu hohen Frequenz gefüttert wird. Es ist etwas umfangreich, aber hier der Link zur vollständigen Beschreibung, was man mit diesem Parameter tun kann: distro.ibiblio.org/fatdog/web/fa … html#video[/li][/ul]

viele Grüße
Frank Greif.

Hallo Frank,

vorab schon mal vielen Dank für Deine Hilfe!

Leider führten auch diese Versuche noch nicht zum gewünschten Ergebnis. Das Einsetzen von “nomodeset” änderte nichts am Verhalten.

Anschliessend habe ich dann (ohne nomodeset) eingetragen:

video=VGA:1024x768@60 e
video=HDMI-A d

um einerseits den HDMI-Ausgang sicher abzuschalten und anderseits eine vom Monitor sicher unterstützte Auflösung/Frequenz zu wählen.
Leider mit exakt dem gleichen Ergebnis. Bei beiden Versuchen wird wie schon zuvor der Monitor nach der Anzeige der Univention-Logos nach knapp 3sec dunkel. Es liegt dann wohl gar kein Signal mehr am Monitor an, denn ich kann dann weder über die Auto-Kalibrier-Funktion am Monitor etwas bewirken, noch zeigt der Monitor die Meldung mit der zu hohen Videofrequenz an. Diese kommt nur bei der Eingabe von set vbe_mode=0xXXX und videotest.

Ist wohl doch ein verzwickter Fall…

Gruß
Uwe

Hallo Uwe,

mir fällt auf, daß Du immer ein Leerzeichen vor dem “Enable/Disable” Parameter angibst, das steht in der Beschreibung nicht so drin. Und auch wenn “d” ausgewählt ist, muß wahrscheinlich trotzdem eine Auflösung angegeben werden, da “res” nicht in eckigen Klammern steht. Ansonsten hab ich momentan keine weiteren Ideen, hab auch schon in der Kernel-Doku geschaut, für welche Grafik-Chips es überhaupt Framebuffer Unterstützung gibt, da steht dieser Atom nicht dabei. Ich würde höchstens mal noch die Gegenprobe mit einem HDMI Adapter machen, oder noch schauen, ob man im BIOS die primäre Anzeige anders einstellen kann.

Meine allerletzte Verzweiflungstat wäre dann eine andere VGA Karte zu nehmen, aber wenn man alles per SSH erledigen kann, muß das ja doch nicht nötig sein.

viele Grüße
Frank Greif.

Hallo Frank,

leider konnte ich erst jetzt wieder weiter testen.
Meine Einträge in den Bootoptionen sahen nun so aus:

video=VGA:1024x768@60e
video=HDMI-A:800x600d

das Ergebnis bleibt immer noch das gleiche.

Einen HDMI-Adapter habe ich leider nicht zur Verfügung, auch keinen Monitor mit HDMI-Anschluß. Im BIOS hatte ich schon zu Beginn der Versuche die Anzeigeoptionen gecheckt. Da steht der primäre Port auf VGA und der HDMI-Port ist ausgeschaltet.

In der Zwischenzeit hatte ich einmal den Rechner mit einem Ubuntu-Live-System von einem USB-Stick gestartet. Das funktioniert sowohl mit einem älteren Ubuntu 12.04 als auch mit dem neuesten 13.10 tadellos. Da Ubuntu 13.10 in einer höheren Auflösung startet habe ich hierzu nochmals einen neueren Bildschirm angeschlossen und auch mit diesem die vorangegangenen Tests wiederholt. Beim Booten des UCS ergibt sich trotzdem keine Verbesserung. Der Anzeigefehler tritt also offensichtlich nur beim Booten des UCS auf. Könnte das Problem daher nicht doch eventuell eine fehlerhafte Konfiguration im UCS-System sein? UCS als auch Ubuntu basieren ja auf Debian, ich hätte jetzt deswegen den gleichen Anzeigefehler beim aktuellen Ubuntu 13.10 erwartet.

Mir ist dazu jetzt noch ein anderer Ansatz eingefallen:
In der UMC hatte ich vor einiger Zeit unter Basis-Einstellungen/Software die Desktop-Umgebung testweise deinstalliert und später wieder installiert. Vielleicht ist dabei etwas nicht korrekt eingerichtet worden?

Gruß
Uwe

So, nun gibt es im neuen Jahr doch noch erfreuliche Neuigkeiten.

Bei meiner weiteren Suche habe ich in verschiedenen anderen Foren die Lösung für mein Problem gefunden. Frank, Du hattest bereits völlig Recht mit Deiner Vermutung das die nicht vorhandene Bildschirmanzeige mit den Anschlüssen der Grafikkarte zusammenhängt. Mein Board hat aber nicht nur wie ich glaubte einen VGA- und einen HDMI-Ausgang. Es gibt intern auch noch einen “LVDS-connector”. Bislang wusste ich gar nicht das es so etwas gibt. Die Lösung für mein Problem war nun den LVDS-Port zu deaktivieren. In der Kernel-Kommandozeile ist einzusetzen:

video=LVDS-1:d

Damit diese Änderung dauerhaft im System verbleibt und auch bei Installation eines neuen Kernels übernommen wird habe ich die UCR-Variable grub/append auf video=LVDS-1:d gesetzt. Ich hoffe das dies so richtig ist und den gewünschten Effeckt hat. Zusätzlich habe ich dann noch grub/bootsplash auf nosplash geändert. Seitdem bin ich an der Konsole des Servers nicht mehr blind. Damit kann ich mich demnächst etwas beruhigter an das Update auf 3.2-0 machen.

Vielen Dank an Frank. Mit Deinen Tipps hast Du mich in die richtige Richtung gebracht!

Gruß
Uwe

Mastodon