FS#68924 - Logging in with TTY session fails after recent update.

Attached to Project: Arch Linux
Opened by Adam Jimerson (vendion) - Thursday, 10 December 2020, 15:00 GMT
Last edited by Doug Newgard (Scimmia) - Friday, 11 December 2020, 04:16 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To No-one
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
After a recent update and reboot, due to linux the 5.9.12.arch1-1 -> 5.9.13.arch1-1 update that hit the core repos recently logging into the TTY session fails.
Once the system finishing booting the getty process successfully restarts and displays the login prompt as expected, but after entering my username and pressing the Enter key instead of being prompted for my password it seems as though the getty session gets restarted and I'm again prompted for my username. I have since rolled my system back to a backup from before the update was done and everything is working again as expected but due to this I have lost any system logs that may have given any pointers as to why getty was crashing/restarting after I entered in my username. This happened for both my normal system user and when trying to login as root.

Additional info:
Below is the list of packages that pacman will currently want to update when running `pacman -Syu`:

49 community/bbswitch 0.8-368 -> 0.8-369
48 community/ceph-libs 15.2.6-2 -> 15.2.6-3
47 community/fwupd 1.5.2-2 -> 1.5.3-1
46 community/haskell-aeson 1.5.4.1-18 -> 1.5.4.1-19
45 community/haskell-strict 0.4-28 -> 0.4.0.1-1
44 community/ncmpcpp 0.8.2-12 -> 0.8.2-13
43 community/nodejs 15.3.0-1 -> 15.4.0-1
42 community/opera-ffmpeg-codecs 86.0.4240.198-1 -> 86.0.4240.198-3
41 community/pamixer 1.4-3 -> 1.4-4
40 community/perl-lingua-en-inflect 1.904-3 -> 1.905-1
39 community/shellcheck 0.7.1-204 -> 0.7.1-207
38 community/virtualbox-host-modules-arch 6.1.16-13 -> 6.1.16-14
37 community/youtube-dl 2020.12.07-1 -> 2020.12.09-1
36 core/bash 5.0.018-2 -> 5.1.0-2
35 core/linux 5.9.12.arch1-1 -> 5.9.13.arch1-1
34 core/readline 8.0.004-1 -> 8.1.0-2
33 core/sudo 1.9.4-1 -> 1.9.4-2
32 core/systemd 247.1-1 -> 247.1-3
31 core/systemd-libs 247.1-1 -> 247.1-3
30 core/systemd-resolvconf 247.1-1 -> 247.1-3
29 core/systemd-sysvcompat 247.1-1 -> 247.1-3
28 extra/apparmor 3.0.0-3 -> 3.0.1-1
27 extra/boost-libs 1.72.0-4 -> 1.74.0-2
26 extra/foomatic-db-gutenprint-ppds 5.3.3-2 -> 5.3.4-1
25 extra/fprintd 1.90.1-1 -> 1.90.7-1
24 extra/gdk-pixbuf2 2.42.0-2 -> 2.42.2-1
23 extra/gutenprint 5.3.3-2 -> 5.3.4-1
22 extra/hplip 1:3.20.11-1 -> 1:3.20.11-2
21 extra/libcmis 0.5.2-4 -> 0.5.2-5
20 extra/libfprint 1.90.3-1 -> 1.90.6-1
19 extra/libixion 0.16.1-3 -> 0.16.1-4
18 extra/libkolabxml 1.1.6-13 -> 1.1.6-14
17 extra/liborcus 0.16.1-3 -> 0.16.1-4
16 extra/libreoffice-fresh 7.0.3-4 -> 7.0.3-5
15 extra/mesa 20.3.0-2 -> 20.3.0-3
14 extra/nvidia 455.45.01-5 -> 455.45.01-6
13 extra/opencl-mesa 20.3.0-2 -> 20.3.0-3
12 extra/openexr 2.5.3-3 -> 2.5.3-4
11 extra/openjpeg2 2.3.1-2 -> 2.3.1-3
10 extra/postgresql-libs 12.5-4 -> 13.1-2
9 extra/python-cryptography 3.2.1-3 -> 3.3-1
8 extra/python2-cryptography 3.2.1-3 -> 3.3-1
7 extra/sbc 1.4-2 -> 1.5-1
6 extra/source-highlight 3.1.9-2 -> 3.1.9-3
5 extra/tracker3 3.0.1-1 -> 3.0.2-1
4 multilib/lib32-gdk-pixbuf2 2.42.0-2 -> 2.42.2-1
3 multilib/lib32-readline 8.0.004-1 -> 8.1.0-2

When this first started happening before deciding to restore from my backup I did try to install the previous versions of the linux, nvidia, and systemd packages that were upgraded but I got the same result.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Friday, 11 December 2020, 04:16 GMT
Reason for closing:  Not a bug
Comment by Doug Newgard (Scimmia) - Thursday, 10 December 2020, 15:10 GMT
Without logs, there nothing to be done here. I would guess you're using bash and it wouldn't run, but who knows.
Comment by Adam Jimerson (vendion) - Friday, 11 December 2020, 03:51 GMT
Well the root user on my system is using bash for the login shell yes, but my normal user is using a different shell (Elvish) for its login shell so I doubt that is the issue as the same thing was happening with both users. Plus unless the getty process tries to spawn a new shell instance between prompting for the username and the password that doesn't seem to make any sense why the getty process would restart before it could ask for my password.
Comment by Doug Newgard (Scimmia) - Friday, 11 December 2020, 03:59 GMT
If the login shell crashes/refuses to start, it will log you out, so it would make sense. Since the user isn't on bash, though, it may not. We're back to requiring logs. Honestly, though, since there hasn't been a big outcry, I'm guessing this is a local issue better solved on the forums, IRC, or mailing lists.
Comment by Adam Jimerson (vendion) - Friday, 11 December 2020, 04:04 GMT
As I need this machine for work I'll hold off trying another update until this weekend and if it happens again then I'll grab the logs before rolling back again and go from there then.
Comment by Doug Newgard (Scimmia) - Friday, 11 December 2020, 04:16 GMT
Let's follow up on the support channels at that point. I'll close this for now and you can request that it be reopened if it's determined to be a package issue.

Loading...