SDDM auf Konsole 2 statt 7 - falsche Rechte
EDIT 14.10.'23:
Die Beschreibung da unten behebt das Problem nur halb: Beim ersten Booten startet SDDM noch immer auf VT2. Erst ein restart des display-manager landet dann wie gewollt auf VT7. Keine Ahnung, was da abgeht.
ORIGINALER TEXT:
Ist wieder einer dieser Tage heute, die keinen Sinn machen. Ich habe vor Kurzem festgestellt, dass auf dem Desktop-Rechner seit Neuestem der Display Manager nicht mehr - wie gewohnt - auf VT7 startet, sondern auf VT2. Machte jetzt für mich erst Mal keinen Sinn, denn ich habe an den Konfigurationsdateien seit Jahren nichts geändert. An allen relevanten Stellen steht auch brav drin, dass SDDM doch bitte auf Konsole 7 starten möge.
Nachdem ich dann auch im Netz nichts Sinnvolles gefunden habe, habe ich mich schweren Herzens dazu entschlossen, doch mal die böse AI zu fragen. Die hat zwar auch keine Ahnung und sülzt mich immer mit allem möglichen zu, was ich nicht wissen wollte und auch gar nicht relevant für mein Problem ist, aber sie bringt mich hin und wieder auf neue Ideen, woran es denn noch liegen könnte. Dieses Mal war es ganz ähnlich: Nachdem mir der ChatBot vorgeschlagen hat, ich solle doch einfach eine Neuinstallation machen - Ja, sicher! So seh ich aus, was? -, habe ich der Reihe nach einfach noch Mal alle Dateien angeschaut, die irgendwie mit dem Display Manager und sddm in Verbindung stehen. Und dabei ist mit aufgefallen, dass sddm gar nicht in der tty-Gruppe drin ist. Vielleicht liegt es also daran?
Die Antwort ist ein ganz klares Jein. Ich mein, offenbar war der User sddm auch vorher nicht in dieser Gruppe, als das noch geklappt hat. Ein Blick auf
)
Ich habe jetzt also sddm in die tty-Gruppe hinzugefügt, ein local.d-Start-Script angelegt, dass chmod g+r /dev/tty7 ausführt, dem sddm-init-Script ein
)
Die Beschreibung da unten behebt das Problem nur halb: Beim ersten Booten startet SDDM noch immer auf VT2. Erst ein restart des display-manager landet dann wie gewollt auf VT7. Keine Ahnung, was da abgeht.
ORIGINALER TEXT:
Ist wieder einer dieser Tage heute, die keinen Sinn machen. Ich habe vor Kurzem festgestellt, dass auf dem Desktop-Rechner seit Neuestem der Display Manager nicht mehr - wie gewohnt - auf VT7 startet, sondern auf VT2. Machte jetzt für mich erst Mal keinen Sinn, denn ich habe an den Konfigurationsdateien seit Jahren nichts geändert. An allen relevanten Stellen steht auch brav drin, dass SDDM doch bitte auf Konsole 7 starten möge.
Nachdem ich dann auch im Netz nichts Sinnvolles gefunden habe, habe ich mich schweren Herzens dazu entschlossen, doch mal die böse AI zu fragen. Die hat zwar auch keine Ahnung und sülzt mich immer mit allem möglichen zu, was ich nicht wissen wollte und auch gar nicht relevant für mein Problem ist, aber sie bringt mich hin und wieder auf neue Ideen, woran es denn noch liegen könnte. Dieses Mal war es ganz ähnlich: Nachdem mir der ChatBot vorgeschlagen hat, ich solle doch einfach eine Neuinstallation machen - Ja, sicher! So seh ich aus, was? -, habe ich der Reihe nach einfach noch Mal alle Dateien angeschaut, die irgendwie mit dem Display Manager und sddm in Verbindung stehen. Und dabei ist mit aufgefallen, dass sddm gar nicht in der tty-Gruppe drin ist. Vielleicht liegt es also daran?
Die Antwort ist ein ganz klares Jein. Ich mein, offenbar war der User sddm auch vorher nicht in dieser Gruppe, als das noch geklappt hat. Ein Blick auf
stat -c '%a %U:%G %n' /dev/tty? verrät mir dann auch, dass eigentlich gerade niemand Zugriff auf die Konsolen haben dürfte, die gehören nämlich alle root:tty, sind aber auf 620 gestellt. (Was die Frage aufwirft: Wie konnte sddm dann auf tty2 starten? Liegt das daran, dass da eigentlich schon eine Text-Konsole läuft und sich das da irgendwie dran hängen kann?) (Bei der Gelegenheit übrigens gelernt, dass man mit startx -- vt7 das X11 zwingen kann, auf einer bestimmten Konsole zu starten - was in diesem Fall erst zu einem "Permission Denied" - HINT! HINT! - geführt hat und dann zu einer X-Session, in der die Tastatur und Maus nicht an die Session gebunden waren, sodass ich vom Handy aus per ssh erst mal alles killen durfte! Wieder erfolgreich in den Fuß geschossen! )Ich habe jetzt also sddm in die tty-Gruppe hinzugefügt, ein local.d-Start-Script angelegt, dass chmod g+r /dev/tty7 ausführt, dem sddm-init-Script ein
after local hinzugefügt und jetzt geht es. Das erscheint mit alles noch ein bisschen unausgegoren - vor allem bin ich bei der Sicherheits-Problematik noch nicht ganz durchgestiegen, wenn alle tty-Gruppenmitglieder aus /dev/tty7 lesen dürfen; aber ich bin ja auch der einzige, der diesen Rechner benutzt, das sollte eigentlich in Ordnung gehen. Bis ich Zeit habe herauszufinden, was da wirklich vor sich geht, kann ich also fürs Erste damit leben. (Ich vermute, dass die Umstellung bei Gentoo von der alten udev-Implementation auf die im systemctl enthaltene irgendwas durcheinander gebracht hat, vor allem, weil mein System so alt ist, dass es ja noch mit rc gestartet wird. Systemd... pöh... Neumodischer Krams! )