[gelöst] schon wieder kein Login auf den Textkonsolen

[smutbert]

Ab jetzt passe ich auf, ob das auch auftritt, bevor der Bildschirm in einen Stromsparmodus geschickt wird…

Also mit den Stromsparmodi hat es eindeutig nichts zu tun und es tritt mit lightdm/e17 doch genauso auf, wie mit mate und gdm3/gnome. Da war ich wohl etwas voreilig.


systemd-cron ist einfach nur ein Ersatz für cron. Habe ich testweise bereits durch cron ersetzt, ich rechne aber nicht damit, dass das das Problem löst…

[scientific]

systemd-cron ist einfach nur ein Ersatz für cron. Habe ich testweise bereits durch cron ersetzt, ich rechne aber nicht damit, dass das das Problem löst…

Na vielleicht wird mit systemd-cron irgend ein unit-file gestartet, welches dir nach einer Zeit die gettys wegnimmt... Deaktivier oder deinstallier den mal probehalber (oder gibts da irgendwelche logs dazu? Hab den noch nicht in Verwendung...)

lg scientific

[smutbert]

Das Ersetzen von systemd-cron durch cron gestaltet sich etwas schwieriger als erwartet: 38110

…und jetzt kann ich das System auch nicht mehr herunterfahren oder neu starten

Code: Alles auswählen

…
# reboot
Failed to start reboot.target: Activation of org.freedesktop.systemd1 timed out
Failed to open initctl FIFO: No such device or address
Failed to talk to init daemon.
# systemctl reboot

Failed to start reboot.target: Activation of org.freedesktop.systemd1 timed out

[WernerFP]

Ich habe vorhin ein dist-upgrade durchgeführt und die Textkonsolen werden bei mir nun wieder erwartungsgemäß ausgeführt.
Zuvor hatte ich identische Ausgaben wie ihr und die gleiche Symptomatik (Jessie, Gnome).
Was reinkam:

Code: Alles auswählen

$ tail -n 5 /var/log/apt/history.log | sed 's/), /)\n/g'
Start-Date: 2014-11-22  18:02:18
Commandline: apt-get dist-upgrade
Install: nvidia-driver-bin:amd64 (340.46-4, automatic)
Upgrade: initscripts:amd64 (2.88dsf-57, 2.88dsf-58)
geoip-database:amd64 (20141009-1, 20141027-1)
nvidia-alternative:amd64 (340.46-3, 340.46-4)
firebird2.5-server-common:amd64 (2.5.3.26778.ds4-3+b1, 2.5.3.26778.ds4-4)
libegl1-nvidia:amd64 (340.46-3, 340.46-4)
libgles2-nvidia:amd64 (340.46-3, 340.46-4)
libsane-common:amd64 (1.0.24-3, 1.0.24-4)
nvidia-driver:amd64 (340.46-3, 340.46-4)
pidgin-data:amd64 (2.10.10-1, 2.10.10-1.1)
xserver-xorg-video-nvidia:amd64 (340.46-3, 340.46-4)
libfbclient2:amd64 (2.5.3.26778.ds4-3+b1, 2.5.3.26778.ds4-4)
vim-common:amd64 (7.4.488-1, 7.4.488-2)
firebird2.5-common-doc:amd64 (2.5.3.26778.ds4-3, 2.5.3.26778.ds4-4)
libgl1-nvidia-glx-i386:i386 (340.46-3, 340.46-4)
meld:amd64 (3.12.0-1, 3.12.1-1)
dh-python:amd64 (1.20141026-1, 1.20141111-2)
dosfstools:amd64 (3.0.26-4, 3.0.27-1)
rtkit:amd64 (0.11-1, 0.11-2)
libqpdf13:amd64 (5.1.2-1, 5.1.2-2)
qpdf:amd64 (5.1.2-1, 5.1.2-2)
libfbembed2.5:amd64 (2.5.3.26778.ds4-3+b1, 2.5.3.26778.ds4-4)
libsane:amd64 (1.0.24-3, 1.0.24-4)
libpurple0:amd64 (2.10.10-1, 2.10.10-1.1)
vim-tiny:amd64 (7.4.488-1, 7.4.488-2)
libgdbm3:amd64 (1.8.3-13+b1, 1.8.3-13.1)
libgl1-nvidia-glx:amd64 (340.46-3, 340.46-4)
libgl1-nvidia-glx:i386 (340.46-3, 340.46-4)
lintian:amd64 (2.5.30, 2.5.30+deb8u2)
nvidia-kernel-dkms:amd64 (340.46-3, 340.46-4)
sane-utils:amd64 (1.0.24-3, 1.0.24-4)
sysv-rc:amd64 (2.88dsf-57, 2.88dsf-58)
libgles1-nvidia:amd64 (340.46-3, 340.46-4)
libpurple-bin:amd64 (2.10.10-1, 2.10.10-1.1)
libjackson2-core-java:amd64 (2.4.2-1, 2.4.2-2)
libnvidia-ml1:amd64 (340.46-3, 340.46-4)
firebird2.5-common:amd64 (2.5.3.26778.ds4-3, 2.5.3.26778.ds4-4)
sysvinit-utils:amd64 (2.88dsf-57, 2.88dsf-58)
nvidia-vdpau-driver:amd64 (340.46-3, 340.46-4)
whois:amd64 (5.2.1, 5.2.2)
libgeoip1:amd64 (1.6.2-1, 1.6.2-2)
libtheora0:amd64 (1.1.1+dfsg.1-5, 1.1.1+dfsg.1-6)
libnvidia-eglcore:amd64 (340.46-3, 340.46-4)
End-Date: 2014-11-22  18:03:31

Könnten die initscripts evtl. was damit zu tun gehabt haben? In den Bugreports habe ich nichts gefunden...
Ich hoffe mal, dass sich das Problem auch bei euch mit dem nächsten dist-upgrade in Wohgefallen auflöst.

Gruß
WernerFP

[smutbert]

Die Pakete sind alle auf dem aktuellen Stand bei meinem jessie. Zusätzlich habe Kernel 3.17 aus experimental installiert, mit dem tritt das Problem auch auf (aber sonst funktioniert er problemlos).

[smutbert]

Wie eine neue Erkenntnis:
VT1-VT6 waren gerade wieder funktionslos als ich die Gnome-Shell neu gestartet habe (Alt+F2 und r). Der Neustart der Gnome-Shell hat zwar merkwürdig lange gedauert, aber danach haben die VTs wieder funktioniert.
Jetzt ein paar Minuten später funktionieren sie allerdings schon wieder nicht. Es hat aber doch den Anschein, als hätte das ganze irgendetwas mit X zu tun.

[WernerFP]

Ich glaube auch nicht so recht daran, dass das Problem unmittelbar mit systemd zusammenhängt. Dann schon eher mit X. Ich habe 2 Rechner mit Testing, beide mit systemd 215-5+b1:

--> Bei dem einen Rechner hatte ich das letzte dist-upgrade am 05.11.2014 durchgeführt. Der hatte weiterhin Zugriff auf die Textkonsolen. (Intel-Grafik).
--> Bei dem anderen Rechner hatte ich das letzte dist-upgrade am 17.11.2014. Der hatte dann bei gleicher systemd-Version plötzlich keinen Zugriff mehr auf die Konsolen. (Nvidia-Grafik)

Die relevanten Ausgabe waren bei beiden Rechnern deckungsgleich mit den Ausgaben, die du gepostet hast. Nach dem gestrigen dist-upgrade waren die Textkonsolen plötzlich wieder da.
An den reingekommenen Paketen kann die Lösung des Problems nicht liegen, jedenfalls sehe ich da nichts Relevantes. Und bei den initscipts wurde bloß ein Tippfehler im Zusammenhang mit upstart gefixt – > 768496.

Aber: Mit dem Nvidia-Update wurde durch DKMS ein update-initframs angestoßen. Eventuell könnte ein ja ein manuelles update-initframs die Lösung des Problems sein.

Gruß,
WernerFP

[smutbert]

Verzeihung für das Hervorholen des Themas, aber langsam verzweifle ich etwas…

Bei zwei neuen gedebootstrappten Installationen dasselbe beschriebene Verhalten:
Nach dem Systemstart funktioniert für einige Minuten bis zu vielleicht einer halben Stunde alles, danach zeigen die Text-VTs nur mehr eingefroren den letzten Zustand, egal ob es irgendein Text aus einer Kommandozeilensitzung, der Login, oder ein leerer Bildschirm ist (letzteres passiert mit dem dynamischen starten der gettys von systemd, wenn man in den ersten Minuten nicht auf ein VT schaltet).

Keine Meldungen, keine Logeinträge, laut systemctl laufen alle gettys und werden auch dynamisch nachgeladen falls notwendig, aber die Anzeige funktioniert nicht. X funktioniert problemlos und ich finde keinen Hinweis, dass irgendjemand außer mir auch dieses Problem hätte.

Es handelt sich um Haswell-Rechner mit Kernel 3.16.0-4-amd64 und ich habe bis jetzt weder einen Zusammenhang mit einem Displaymanager, Desktop noch einem Stromsparmodus oder etwas anderem entdecken können.

[rendegast]

Die idee mit einem Grafikproblem halte ich für interessant.

... erhalte ich nur einen statischen Textbildschirm, entweder mit dem Inhalt, der zum letzten Mal auf einem der VTs zu sehen war oder einfach nur einen leeren, machmal mit, manches Mal ohne einen (nicht blickenden) Cursor.

Eine wechselnde Anzeige?

Code: Alles auswählen

watch -n1 ls

gäbe einen Zeitcode.
Die (Konsolen)Anzeige könnte per zBsp.

Code: Alles auswählen

screendump 1 > datei

ausgelesen werden. (unabhängig von der Bildschirm-Ausgabe)

Ein eingegebener Befehl wird ausgeführt? (auch mit fehlender/fehlerhafter Anzeige)
Sowas wie

Code: Alles auswählen

beep -f 1500

oder ein "blinder" Login.


Zielt dahin, daß die jeweiligen Konsolen gar nicht tot sind,
sondern "nur" deren Anzeigen.





Wenn der display-manager gar nicht gestartet wird, das/die grafischen Module nicht geladen werden?
Beim Starten vielleicht (entsprechend)

Code: Alles auswählen

linux .... .... modprobe.blacklist=radeon

(nachher Kontrolle: 'lsmod | grep radeon')

[scientific]

Mir fällt grad das Stichwort "Framebuffer" ein. Damit gabs unter Ubuntu-Gutsy mit nvidia (aber auch zu der Zeit mit Debian und nvidia) häufig Probleme, die sich in buggy Consolen gezeigt haben, die entweder gar nicht funktionierten, oder eingefroren sind...

Mehr fällt mir dazu leider auch nicht ein. Aber vielleicht ist es ja ein sachdienlicher Hinweis.

lg scientific

[smutbert]

mit laufendem watch passiert es genauso, die VT Anzeige sagt

…Tue Dec 16 12:50:55…

und screendump

…Tue Dec 16 14:10:29…

(angemeldet um 12:34:30)


Blindes Anmelden und Ausführen von Befehlen funktioniert tadellos. Das VT zeigt statisch den letzten Inhalt von VT 1 (die Ausgabe von watch) und screendump liefert dagegen richtigerweise

Code: Alles auswählen

Debian GNU/Linux 8 athene tty4

athene login: root
Password:
Last login: Tue Dec 16 12:34:30 CET 2014 on tty1
Linux athene 3.17-1-amd64 #1 SMP Debian 3.17-1~exp1 (2014-10-14) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@athene:~# beep
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
root@athene:~#

(habe statt beep ein gleichnamiges Skript geschrieben und verwendet, das etwas über Alsa abspielt, weil ich keinen Lautsprecher im PC habe)
Das hier ist jetzt der Kernel aus experimental, der verhält sich aber komplett gleich wie 3.16 aus jessie.


Soweit hast du recht rendegast, es sind nur die Anzeigen tot.


Ohne Displaymanager passiert es gar nicht erst, glaube ich, obwohl ich das noch überprüfen muss ­— ich habe es so konfiguriert, dass nur root X starten darf. Blacklisten von radeon wird auch nichts helfen bei meiner Intel Grafik und ohne i915 oder KMS wird mir eine ganze Menge mehr fehlen, aber das werde ich auch noch testen.
Momentan habe ich statt mit systemd mit sysvinit gestartet, nur um zu sehen, ob da ein Zusammenhang besteht oder nicht.

@scientific
Die nvidia-Probleme kenne ich auch, ua deshalb habe ich mich für die Intelgrafik entschieden.

[smutbert]

Es passiert mit sysvinit-core genauso.

[rendegast]

Blacklisten von radeon wird auch nichts helfen bei meiner Intel Grafik

Ich habe oben ein "(entsprechend)" dabei stehen.

und ohne i915 oder KMS wird mir eine ganze Menge mehr fehlen,

Es geht hier nur um den "Proof of concept", ob vielleicht einer dieser höheren KMS-Treiber da mit hineinspielt.
Auch 'i915.modeset=0'
oder 'i915.modeset=-1' (siehe 'modinfo i915'),
um nur das KMS dieses Moduls zu deaktivieren.

Die Graka benutzt wohl vom Hauptspeicher abgezwacktes shared-memory,
da Einstellungen im BIOS? ZBsp. bzgl. der Größe.

[smutbert]

Entschuldige, es war mir schon klar was du meinst - ich wollte nicht i-Tüpferlreiten.

Ich bin gerade auf etwas anderes gestoßen

Code: Alles auswählen

# modprobe -c | grep i915 | grep "^options"
options i915 fastboot=1

hat sich in einer Datei in /etc/modprobe.d vor mir versteckt. Jetzt habe ich es auskommentiert und warte gespannt…

[smutbert]

Seit gestern keine Probleme mehr ­— das war wirklich diese Option von i915.

Code: Alles auswählen

# modinfo i915 | grep fastboot
parm:           fastboot:Try to skip unnecessary mode sets at boot time (default: false) (bool)

Offensichtlich sind die übersprungenen mode sets (ist damit das Einstellen von Bildschirmwiederholrate und Auflösung gemeint?) doch nicht so überflüssig. Das ganze habe ich übersehen, weil das in einer /etc/modprobe.d/local.conf steht, die ich schon lange unverändert von Installation zu Installation mitnehme.

Danke noch einmal an alle!

[catdog2]

Offensichtlich sind die übersprungenen mode sets (ist damit das Einstellen von Bildschirmwiederholrate und Auflösung gemeint?) doch nicht so überflüssig.

Solche Modulparameter existieren meistens weil bekannt ist, dass das Feature (noch) nicht (überall) fehlerfrei läuft.

[smutbert]

zu meiner Verteidigung darf ich vielleicht erwähnen, dass ich das in meine modprobe.d/local.conf geschrieben habe, als Wheezy noch testing war, es seitdem, bis vor kurzem in jessie immer funktioniert hat und ich, ohne einen Gedanken daran zu verschwenden, selbige local.conf mit der Neuinstallation einfach übernommen habe.