(gelöst) GUI auf tty7 ohne systemd

[guennid]

Wie kriegt man die GUI (openbox) ohne systemd und ohne Login-Manager auf tty7? Ich habe das hier auf einer Maschine seit Jahren (vermutlich seit wheezy) unter stretch am laufen, weiß aber nicht mehr, wie ich's (mit Hilfe aus dem DF) damals eingerichtet habe. Den Thread finde ich nicht mehr. KP97 war beteiligt, wenn ich recht erinnere.

Grüße,Günther

[MartinV]

Ich weiß nicht, wie/wo Du X startest. Im X Befehl kannst Du die Option -vt7 für tty7 angeben.

[uname]

Die Frage ist eigentlich, ob sich beim Start des Systems der Benutzer automatisch an der Konsole tty7 anmeldet. Ohne Systemd ging das mal mit /etc/inittab.
Wird dann über z. B. ~/.profile oder ~/.bash_profile usw. vielleicht xinit und damit X11 gestartet? Ob und wie auf tty7 weiß ich nicht.
Wird vielleicht dann über ~/.xinitrc openbox aufgerufen?

Was steht in den ganzen von mir genannten Konfigurationsdateien?

Lese viewtopic.php?t=153249

Von shell-Syntax verstehe ich nichts. In wheezy hätte es ein einfaches "startx" in ~/.profile (oder .xinitrc) auch getan (sofern es NUR um den Fuxbox-Start geht). openbox will in ~/.xinitrc ganz gerne eine Zeile openbox-session drin haben und verlegt die Einzelheiten dann nach ~/.config/openbox. Ob's bei fluxbox Ähnliches gibt, weiß ich nicht.

[guennid]

Auf der Maschine, auf der es wie gewünscht läuft, ist in ~/.profile startx eingetragen, ohne Parameter.

~/.xinitrc:

Code: Alles auswählen

fbpanel &
openbox-session

OT: Du hast gepostet, während ich editierte. Der letzte Post ist im Voranstehenden noch nicht von mir verarbeitet.

Grüße, Günther

edit:
/etc/inittab hatte ich auch im Verdacht. Aber das erscheint mir als nicht von mir verändert:

Code: Alles auswählen

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

oder gibt es einen anderen Abschnitt, den ich nicht erinnere?

edit2:
startx um -vt7 zu erweitern funktioniert nicht:

Code: Alles auswählen

xinit: Unable to run program "/usr/bin/xterm": No such file or directory

Hmmm...
Statt xterm verwende ich rxvt-unicode (urxvt).

[uname]

Funktioniert denn überhaupt der Aufruf von xinit? Wenn ja wo wird X11 bzw. openbox gestartet?
Wird beim Hochfahren der Benutzer direkt angemeldet bzw. wolltest du das einrichten? Früher habe ich rungetty in /etc/inittab genutzt.
Ich denke mal einen Display-Manager wie nodm willst du nicht verwenden.

Info zu NODM: https://wiki.debianforum.de/Display-Manager#NODM

Statt xterm verwende ich rxvt-unicode (urxvt).

Ändere die Konfiguration der installiere testweise xterm.

Suche nach xterm. Ich nehme dafür immer die große Keule:

Code: Alles auswählen

fgrep -R xterm /etc
fgrep -R xterm /home/user

Irgendwo steht es ... vielleicht.

[MartinV]

> startx um -vt7 zu erweitern funktioniert nicht:

Probiere:

Code: Alles auswählen

startx -- vt7

startx-Argumente vor -- gehen an xterm oder sh und dienen dazu, .xinitrc auszuführen. Die Fehlermeldung sieht komisch aus,aber egal. Brauchen wir hier nicht.

Argumente nach -- gehen an den X server.
(Fehler meinerseits: vt7 muß ohne - angegeben werden.)

[guennid]

Hmmm ...

Ich fürchte wir kommen hier jetzt ein wenig durcheinander. Während uname offenbar das Ziel verfolgt, rauszubekommen, wie es funktioniert auf der Maschine, auf der es funktioniert, verfolgt Martin eher den Plan, wie es denn auf einer neu zu konfigurierenden Maschine zum Laufen zu bringen sein könnte.

zu uname:

Funktioniert denn überhaupt der Aufruf von xinit?

Davon gehe ich aus. Ich bekomme ja die openbox-GUI, wie eingerichtet, auf ttY7. Es gibt kein autologin. Ich logge mich auf der Konsole (tty1) als user ein. Danach wird, wenn ich recht sehe, ~/.profile aktiviert, in der am Schluss steht: startx. Das wiederum startet ~/.xinitrc mit fbpanel und openbox-session. Das Weitere steht dann in ~/config/openbox/autostart.

zu MartinV
Ich werd's an einer anderen Maschine ausprobieren.

[guennid]

Martins Vorschlag funktioniert!

Auf der Testmaschine ist mein startx zwar noch etwas besser versteckt als in ~.profile (weil ich dort statt fbpanel tint2 mit selbstgestrickter menu.xml verwende, mir die Option auf fbpanel aber weiterhin offenhalten will ) aber mit

Code: Alles auswählen

startx -- vt7

in diesem script passiert das Gewünschte. Nichtsdestotrotz wüsste ich immer noch gerne, wie ich das vor Zeiten auf der anderen Maschine bewerkstelligt habe.

[uname]

Ich habe noch etwas gesucht. Evtl. steht was in den beiden Konfigurationsdateien in /etc/X11/xinit , wo du noch mal suchen kannst.
Vor allen /etc/X11/xinit/xserverrc könnte interessant sein siehe weiter unten.

Auch wenn du systemd nicht verwendest habe ich dazu noch etwas komisches gefunden:

d/p/10-startx-Under-Linux-start-X-on-the-current-VT.patch,

Mit kurzer Suche habe ich folgendes gefunden:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1247484

-> https://bugs.debian.org/cgi-bin/bugrepo ... bug=743015

Leider verstehe ich es nicht, da ich mittlerweile systemd mit lightdm nutze.
Es scheint aber so zu sein, dass systemd wohl einen Start von X bei startx auf der identischen Konsole voraussetzt bzw. vorausgesetzt hat.
Es wurde zwar irgendwas gefixt aber vielleicht erkennt man dadurch die Zusammenhänge. Vielleicht ist es aber auch vollkommen unbedeutend.

Evtl. hilft die im letzten Link angegebene Information bzgl. /etc/X11/xinit/xserverrc

Code: Alles auswählen

exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR

und damit evtl.

Code: Alles auswählen

exec /usr/bin/X -nolisten tcp "$@" vt7

Wobei damit das Problem eigentlich nur von xinit auf X verlagert wird.
Insgesamt kann es aber sein, dass in Versionen vor systemd immer tty7 verwendet wurde. Evtl. gibt es dafür irgendeine Default-Konfiguration, die ich aber nicht gefunden habe.
Evtl. ist es an /etc/inittab ersichtlich, die du leider nur bis zu tty6 gepostet hast.
Evtl. erst mit systemd war wie oben in den Links geschrieben scheinbar die Abhängigkeit zum Anmelde-tty gegeben.

[guennid]

Bingo uname!

/etc/X11/xinit/xserverrc hatte ich schon anfangs auf dem Schirm, habe die Datei aber wohl nur auf dem Testrechner gelesen (Martins Weg).

Und die habe ich wohl tatsächlich auf der „funktionierenden“ Maschine von

Code: Alles auswählen

exec /usr/bin/X -nolisten tcp "$@"

auf

Code: Alles auswählen

exec /usr/bin/X -nolisten tcp -novtswitch

geändert. Frag mich nicht, wo ich das her habe, aber ich meine, es sei unter Mitwirkung von DFlern entstanden. KP97 habe ich im Verdacht , aber ich habe ums Verrecken keine Suchbegriffe für die SuFu gefunden, die das hätten bestätigen können, und ich irre häufig bei meinen Erinnerungen. Jedenfalls liefert die xserverrc in dieser Form auch auf der Testmaschine (fast) das gleiche Ergebnis wie auf der „funktionierenden“. Aber Martins Vorschlag hinterlässt auf tty1 mehr Informationen über /tint2fbpanel und openbox als die geänderte xserverrc

Ich habe mit der Titelfage lange gezögert, weil ich keine Lust hatte angemacht zu werden, wegen meiner Vorbehalte gegenüber systemd.

Grüße, Günther

[MartinV]

Ich habe mit der Titelfage lange gezögert, weil ich keine Lust hatte angemacht zu werden, wegen meiner Vorbehalte gegenüber systemd.

*steinschmeiß*

Ich finde es gut, alternative Wege zu erkunden.

[guennid]

Auf der „Testmaschine“ läuft openrc statt sysVinit. Ich hatte bisher keine Probleme.

Oha! sysvinit gibt's nicht mehr in buster - richtig?

[uname]

Frag mich nicht, wo ich das her habe, aber ich meine, es sei unter Mitwirkung von DFlern entstanden. KP97 habe ich im Verdacht , aber ich habe ums Verrecken keine Suchbegriffe für die SuFu gefunden, die das hätten bestätigen können, und ich irre häufig bei meinen Erinnerungen.

Das Internet vergisst nie. Man muss nur richtig suchen: viewtopic.php?t=161649

[MartinV]

Oha! sysvinit gibt's nicht mehr in buster - richtig?

Doch: sysvinit-core

[guennid]

Das Internet vergisst nie. Man muss nur richtig suchen

OK, aber auf das obskure "novtswitch" als Suchbegriff war ich nicht gekommen. Abgesehen davon macht der Schalter offenbar genau das Gegenteil dessen, was man seinem Namen gemäß erwartet

[guennid]

Doch: sysvinit-core

Stimmt! Hätt' mir eigentlich einfallen können, dass das wegen systemd umbenannt wurde.

Grüße, Günther