Unable to login to text terminals: System does not let me enter password

I don’t know if relevant to your issue,
Take a look at the following from Lennart Poettering’s blog… I seem to remember there’s another blog article devoted to this topic somewhere but this is what came up with an Internet search… Take note the last couple paragraphs in the VT section…


Bottom line is that when you open a terminal session, you may not be connecting to the specific terminal you think you want, particularly if it’s already being used for something and apparently the Gnome Desktop in particular is known to utilize several terminals. When the terminal is unavailable, systemd will instead utilize whatever is available…


By default and desktop agnostic, openSUSE sets VT’s and Reserved to six (6), there is some other underlying issue that changed over kernels and seems desktop specific…

Hi malcolmlewis,

I am not so much of an expert, I’m afraid. Could we thus briefly get the following straight:

1- What exactly do you mean be ‘DE login’?

2- And what do you mean be 'VT login’?

3- I understand from your previous posting (‘I have no issues with Leap 15.0, GNOME on Xorg and console login’) that you do not have the same a login issue that I have. Do you therefore regard a btmp with 0 bytes normal?

Desktop Environment (I use GNOME as my DE)

Virtual Terminal accessed via ctrl+alt+Fn where n= 1 through 6

Yes, correct, I have no issues switching/logging into a VT (1 through 6) as my user or root, since I see that file (btmp) at zero bytes on Leap 42.3 and 15.0 (x86_64 and aarch64), now on Tumbelweed it’s 384bytes…

Hi all,

Does it make sense to come back to the journal entries regarding the login-try:

xxx@xxx:~> sudo journalctl -b --no-host | grep "tty1"
Dez 21 19:19:02 systemd[1]: Started Getty on tty1.
Dez 21 19:20:51 login[2335]: FAILED LOGIN SESSION FROM tty1 FOR xxx, Authentication token manipulation error
Dez 21 19:20:54 systemd[1]: getty@tty1.service: Service has no hold-off time (RestartSec=0), scheduling restart.
Dez 21 19:20:54 systemd[1]: Stopped Getty on tty1.
Dez 21 19:20:54 systemd[1]: Started Getty on tty1.

Plus these lines:

Dez 21 19:20:51 login[2335]: gkr-pam: couldn't get the password from user: Conversation error
Dez 21 19:20:51 login[2335]: pam_unix(login:auth): conversation failed
Dez 21 19:20:51 login[2335]: pam_unix(login:auth): auth could not identify password for [xxx]

Is this significant in any manner for the issue that we have?

I see;

Dec 21 13:30:05 gekkota-nagios systemd-logind[938]: New session 5 of user xxx
Dec 21 13:30:05 gekkota-nagios login[20268]: pam_unix(login:session): session opened for user xxx by LOGIN(uid=0)
Dec 21 13:30:05 gekkota-nagios login[20268]: LOGIN ON tty2 BY xxx

If you create a test user, login to your test user desktop and then do the switch to a VT, can you login as the test user? It looks like a pam/keyring issue…

Did the following:

1- Created (a new) test user
2- Logged out from KDE
3- Logged into KDE as the test user
4- Changed to VT (Strg-Alt-F1) and tried to login as test user

–> The issue remains the same.

OK, so delete that user and home directory, create the test user again, now just logout of KDE and then switch to a tty and try logging in as the test user. Still the same?

Still the same!

Added another little test (just in case it’s relevant):

Removed the test user AND the auto-login function (via YAST user and group management module) so that I won’t be logged into KDE automatically following boot. After boot and before logging into KDE switched to VT and tried to login:

→ Issue remains the same.

Hi all,

Is there a not too complex way in openSUSE to install an older version of the kernel - say: 4.12.14-lp150.**12.22-**default - as an intermediate remedy?

1- Is there an archive of older official kernel versions accessible somewhere in the openSUSE world to provide for the download?

2- What would I need to consider and what to configure to get this kernel implemented? I assume the basic thing would be to get the respective vmlinuz version into the /boot directory. But what would be more to do? Would there be anything to configure in the /boot directory (or elsewhere) or with Grub (to get it included in the start menu)?

Best regards and thank you very much!

Is it really gone from your system already? 12.22.1 hasn’t been removed from any of mine yet. It’s still in update on the mirrors (no need for separate archive) http://download.opensuse.org/update/leap/15.0/oss/x86_64/kernel-default-4.12.14-lp150.12.22.1.x86_64.rpm and can be reinstalled with zypper --oldpackage or YaST2.

Alright, that worked very fine: Thank you very much, mrmazda! I have done the installation with YaST2 and the kernel version 12.22 is now available in addition to the others in the /boot directory. Also, the symbolic link vmlinuz now points to the 12.22 vmlinuz executable…

However, after the next boot-up things got a bit confusing:

1- The standard item in the Grub boot menu would still boot kernel 12.28
2- In addition to that, the /boot directory seemed to have lost the newly installed files

In fact, there were now two new paired snapshots numbered #2795 and #2796, respectively. The lower numbered #2795 does contain the 12.22 kernel within the /boot directory while snapshot #2796 does not, thus representing the directory version prior to the installation of the 12.22 kernel.

The latter one is the one into which the standard item in the Grub menu boots.

I now wonder how I can safely activate the 12.22 kernel version?

Thanks a lot once again!

It seems that your “old” kernel was purged on the next boot; to keep it you need to add its exact version to the /etc/zypp/multiversion.d/zypp.conf file, search for the line beginning with “multiversion.kernels=” and follow the instructions available just above it.
Ask here if you need help.
Alternatively you can just add “oldest” to the list if you have no other kernel version older than that.
Then reinstall that kernel version… and keep your fingers crossed :wink:

Personally, I would have used Yast Software Management to install kernel 4.12.14-lp150.12.22-default. To do that in Yast, click the “Versions” tab near the bottom of the screen, and check the box for the one that you want to install.

However, your problem is that this will be removed on the next boot, unless you explicitly boot to that kernel.

What you need to do, is edit “/etc/zypp/zypp.conf”.

Look for the line that says:

multiversion.kernels = latest,latest-1,running

and change it to:

multiversion.kernels = oldest,latest,latest-1,running

That way, 12.22 will be kept as the oldest kernel, until you explicitly remove it.

By the way, I had different problems with 12.25, so I made that change here. And I’m keeping 12.22 until I’m sure everything is good. In my case, 12.28 seems to have solved my problems. I will remove 12.22 as soon as there is another good working kernel as the next oldest.

Sorry for a wrong copy/paste, it is /etc/zypp/zypp.conf as nrickert correctly wrote.

Okay guys,

Thanks a lot, indeed! That’s how my /etc/zypp/zypp.conf looks like after I have added 'oldest’:

multiversion = provides:multiversion(kernel)
multiversion.kernels = oldest,latest,latest-1,running

After editing this I have first removed and then re-installed the 12.22 kernel (using YaST as described by nrickert).

After reboot the 12.22 kernel is available in /boot but it’s still the 12.28 kernel that gets actually booted!?

Any further idea on that? Maybe, I should just get rid of the 12.25 and 12.28 kernels…

You can select the “Advanced” menu entry to pick the kernel you want.

As far as I know, “grub2-mkconfig” will always generate a menu that prefers the latest kernel. I don’t know of an easy way to change that, other than manually editing “/boot/grub2/grub.cfg”.

Great, here we go…I’ve got my virtual terminals back…hooray! Thanks a lot for your support once again: I really appreciate that!

To make things easier at boot time, I might still remove the unusable kernel versions…

Bye and have a beautiful day!

I’ll suggest that you just edit “/boot/grub2/grub.cfg”. Look for the first line that begins “linux” (or perhaps “linuxefi”) and change that to the kernel you want. And then change the matching “initrd” line that comes next.

This will stick until “grub2-mkconfig” is next run. That happens on kernel updates, grub updates, shim updates. But most updates won’t affect it.

Yes, you could remove the kernels that you don’t want. But then every time that you do updates, you will find a kernel update ready to reinstall the kernel that you don’t want.