Bugzilla – Bug 1116011
[staging] autologin results in session crash with GDM 3.30.x
Last modified: 2019-05-23 08:44:13 UTC
Identified by openQA: https://openqa.opensuse.org/tests/795647#step/first_boot/2 with GDM 3.30, the session logs in (first_boot is passing, desktop is shown) but shortly after crashes back to the login screen. openSUSE:Factory has been updated to GNOME 3.30 but 'stuck' to gdm 3.28.x due to this reason. But this can't be a long-term solution to keep it like this. The same issue can be observed on the GNOME-Next live media (which is built with gdm 3.30.x as well)
I think the auto login fault is caused by the commit https://gitlab.gnome.org/GNOME/gdm/commit/39fb4ff64e6a0653e70a3bfab31da47b49227d59 We use tty7 to start gdm auto login session. After this commit, gdm will not select tty7, and will find a free tty to start, but get tty1. X start fails on tty1(in log ~/.local/share/xorg/Xorg.0.log), that makes auto login fail.
(In reply to xiaoguang wang from comment #4) > We use tty7 to start gdm auto login session. After this commit, gdm will not > select tty7, and will find a free tty to start, but get tty1. X start fails > on tty1(in log ~/.local/share/xorg/Xorg.0.log), that makes auto login fail. The description why gdm gets free tty from kernel is tty1. Condition: 1. plymouth starts from tty7 2. At the end of gdm starting, gdm kills plymouth service 3. After plymouth service stops, getty@tty1.service will start When gdm want to get a free tty from kernel, getty@tty1.service doesn't start, so gdm gets tty1. Then user session and X start on tty1. After gdm kills plymouth, getty@tty1.service starts up, it occupies the tty1, then X fails, gdm returns to login session. two solutions: 1. revert gdm commit 39fb4ff. 2. change plymouth compile parameter: remove --with-boot-tty=/dev/tty7 Which solution do we want to use? Or we have other solution.
I think 1 (revert gdm commit) is easier in the context of the distro. There are multiple DMs taking care of starting on VT7, and we have the definition that VT1 should always be a text based login - no matter what
After reverting gdm commit 39fb4ff, autologin is successful. But now we find a new bug. After autologin user session is on the tty7, if you switch tty to tty2, and then switch back to tty7, greeter session is brought up on tty7, user session and greeter session is on the same tty7 now, it causes system stuck. According to the upstream gdm code, greeter session and user session don't use the same tty. If user session works on the 'GDM_INITIAL_VT' tty, we will meet the up issue. So I recommend to follow upstream logical, autologin user session doesn't work on tty7, works on other tty except tty1. So we need to add commit 39fb4ff again, and then let gdm not to get tty1 for user session. As I said in #comment 4, gdm will find a free tty from kernel. For the plymouth starts from tty7, so tty1 is always free. How to let gdm not to get tty1, I have two ideas: 1. Before gdm finds free tty, some process(like getty@tty1.service) can occupy the tty1, the kernel will return tty2 when gdm gets free tty. So I changed file '/usr/lib/systemd/system/getty@.service' from: After=systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target to: After=systemd-user-sessions.service getty-pre.target But it doesn't work, gdm still gets tty1 from kernel. From the systemd debuginfo log, I can see the getty@tty1.service is started before display-manager.service. I don't know the reason why gdm still gets tty1. 2. Add a patch on gdm, when free tty from kernel is tty1, we set tty1 busy, then get free tty again, after get other tty successfully, release tty1. Hi Dominique For the idea 1, do you have other good idea? For the idea 2, is adding a patch acceptable? Or you have other good suggestion?
I find a another solution: change file '/etc/systemd/logind.conf' from: #ReserveVT=6 to: ReserveVT=1 It works. gdm get tty2 from kernel.
(In reply to xiaoguang wang from comment #8) > I find a another solution: > > change file '/etc/systemd/logind.conf' > > from: #ReserveVT=6 > to: ReserveVT=1 > > It works. gdm get tty2 from kernel. This sounds pretty clean - This does not conflict with agetty@tty1, right? Then I think this to be the cleanest solution, EXCEPT using a file in /usr/lib/systemd/logind.conf.d/*.conf This would allow an admin to change our default by overriding the same file name in /etc (without us messing with config files)
(In reply to Dominique Leuenberger from comment #9) > (In reply to xiaoguang wang from comment #8) > > I find a another solution: > > > > change file '/etc/systemd/logind.conf' > > > > from: #ReserveVT=6 > > to: ReserveVT=1 > > > > It works. gdm get tty2 from kernel. > > This sounds pretty clean - This does not conflict with agetty@tty1, right? I tested it, didn't conflict with agetty@tty1. > Then I think this to be the cleanest solution, EXCEPT using a file in > > /usr/lib/systemd/logind.conf.d/*.conf > > > This would allow an admin to change our default by overriding the same file > name in /etc (without us messing with config files) I will create a file: /etc/systemd/logind.conf.d/reserveVT.conf [Login] ReserveVT=1 If it's okay, I will create a SR to G:N gdm.
(In reply to xiaoguang wang from comment #10) > I will create a file: > > /etc/systemd/logind.conf.d/reserveVT.conf > [Login] > ReserveVT=1 > > If it's okay, I will create a SR to G:N gdm. All ok, but please /usr/lib/systemd/logind.conf.d/reserveVT.conf
This has been corrected in GNOME:Next. GNOME-Next-Live tests seem to pass, indicating this bug as resolved