Login not possible after upgrade fom Fedora Xfce version 40 to version 41

[Meikel]

Hi folks,

some days ago I did an upgrade of Fedora Xfce from verion 40 to version 
41. I used the method described in "Upgrading Fedora Linux Using DNF 
System Plugin" 
(https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/). 
To me the last step "sudo dnf system-upgrade reboot" did work correctly 
and then reboot the now updated system. At least I see the start screen 
of version 41. But now I'm no longer able to log into the computer, 
neither via GUI/Xfce nor via console/tty.

In the local user database /etc/passwd there are 3 users (meikel, 
sysadmin, backup) and I tried to login with each of them, but with none 
of them I succeeded to log in.

Then I restarted the system from a live USB. From live I was able to 
mount root (/) and home (/home). At a first glance I did not remark 
something special under /home. I just copied all files under /var/log to 
an USB stick for further analysis. I quickly checked in /var/log the 
following files: messages, Xorg.0.log, secure and audit/audit.log but 
it's hard for me to interpret all the messages. In secure I found 
something about unix_chkpwd which might be related to the problem, 
because it concerns all the 3 users (meikel, sysadmin, backup) which I 
tried to log in. I ran

grep "unix_chkpwd" secure

with the following result:

Nov 14 01:30:09 meikel-pc unix_chkpwd[1505]: check pass; user unknown
Nov 14 01:34:49 meikel-pc unix_chkpwd[1522]: check pass; user unknown
Nov 14 01:34:49 meikel-pc unix_chkpwd[1522]: password check failed for 
user (meikel)
Nov 14 01:34:51 meikel-pc unix_chkpwd[1530]: check pass; user unknown
Nov 14 01:34:55 meikel-pc unix_chkpwd[1531]: check pass; user unknown
Nov 14 01:34:55 meikel-pc unix_chkpwd[1531]: password check failed for 
user (meikel)
Nov 14 01:34:56 meikel-pc unix_chkpwd[1533]: check pass; user unknown
Nov 14 01:35:09 meikel-pc unix_chkpwd[1575]: check pass; user unknown
Nov 14 01:35:09 meikel-pc unix_chkpwd[1575]: password check failed for 
user (meikel)
Nov 14 01:35:10 meikel-pc unix_chkpwd[1579]: check pass; user unknown
Nov 14 01:37:13 meikel-pc unix_chkpwd[1487]: check pass; user unknown
Nov 14 01:37:17 meikel-pc unix_chkpwd[1488]: check pass; user unknown
Nov 14 01:37:17 meikel-pc unix_chkpwd[1488]: password check failed for 
user (meikel)
Nov 14 01:37:18 meikel-pc unix_chkpwd[1490]: check pass; user unknown
Nov 14 01:38:28 meikel-pc unix_chkpwd[1482]: check pass; user unknown
Nov 14 01:38:33 meikel-pc unix_chkpwd[1483]: check pass; user unknown
Nov 14 01:38:33 meikel-pc unix_chkpwd[1483]: password check failed for 
user (meikel)
Nov 14 01:38:35 meikel-pc unix_chkpwd[1486]: check pass; user unknown
Nov 14 01:38:48 meikel-pc unix_chkpwd[1490]: check pass; user unknown
Nov 14 01:38:48 meikel-pc unix_chkpwd[1490]: password check failed for 
user (meikel)
Nov 14 01:38:50 meikel-pc unix_chkpwd[1495]: check pass; user unknown
Nov 14 01:40:17 meikel-pc unix_chkpwd[1475]: check pass; user unknown
Nov 14 01:40:25 meikel-pc unix_chkpwd[1478]: check pass; user unknown
Nov 14 01:40:38 meikel-pc unix_chkpwd[1482]: check pass; user unknown
Nov 14 01:40:38 meikel-pc unix_chkpwd[1482]: password check failed for 
user (sysadmin)
Nov 14 01:40:40 meikel-pc unix_chkpwd[1487]: check pass; user unknown
Nov 14 01:40:46 meikel-pc unix_chkpwd[1489]: check pass; user unknown
Nov 14 01:40:54 meikel-pc unix_chkpwd[1493]: check pass; user unknown
Nov 14 01:40:54 meikel-pc unix_chkpwd[1493]: password check failed for 
user (backup)
Nov 14 01:40:56 meikel-pc unix_chkpwd[1501]: check pass; user unknown

I think the time 01:30:09 until 01:40:56 on 11th november corresponds 
exactly to when i treid to log into the system.

What does "unix_chkpwd[....]: check pass; user unknown" mean? Could it 
be a result of the upgrade from 40 to 41? What can I do to be able to 
log into the machine again?

Regards,

Meikel

[Go Canes]

On Mon, Nov 18, 2024 at 9:43 AM Meikel  wrote:
> Nov 14 01:30:09 meikel-pc unix_chkpwd[1505]: check pass; user unknown
> Nov 14 01:34:49 meikel-pc unix_chkpwd[1522]: check pass; user unknown
> Nov 14 01:34:49 meikel-pc unix_chkpwd[1522]: password check failed for
> user (meikel)

Start with the fundamentals.....

ls -l /etc/passwd /etc/shadow

Are the permissions correct?

grep meikel /etc/passwd /etc/shadow

Is the user present in both files?

If the above looks good, try adding a new user and see if you can
login as that user.

[Meikel]

Hi all.
> Start with the fundamentals.....
>  ls -l /etc/passwd /etc/shadow
>
> Are the permissions correct?

I did even a ls -lZ and the permissions look okay for me.
>  grep meikel /etc/passwd /etc/shadow
>
> Is the user present in both files?

Yes, it is.
> If the above looks good, try adding a new user and see if you can
> login as that user.

It is not clear to me how I can do this, as I'm only able to start from 
a live media. If I run something like "useradd" this will add a user on 
the live media, but not on the installed system on the disk. As far as I 
know I need to chroot into the existing installation from the live 
media, but I never did that. With a quick search on the internet I found 
a sample script "Setting up chroot from a live image in Fedora. 
Regenerate grub2 for Fedora." 
(https://gist.github.com/Tamal/73e65bfb0e883e438310c5fe81c5de14) and I'm 
wondering if I could use this as a starting point?

Regards,

Meikel

[Go Canes]

On Tue, Nov 19, 2024 at 8:48 AM Meikel  wrote:
> > If the above looks good, try adding a new user and see if you can
> > login as that user.
>
> It is not clear to me how I can do this, as I'm only able to start from
> a live media. If I run something like "useradd" this will add a user on
> the live media, but not on the installed system on the disk. As far as I
> know I need to chroot into the existing installation from the live
> media, but I never did that. With a quick search on the internet I found
> a sample script "Setting up chroot from a live image in Fedora.
> Regenerate grub2 for Fedora."
> (https://gist.github.com/Tamal/73e65bfb0e883e438310c5fe81c5de14) and I'm
> wondering if I could use this as a starting point?

You can:
- useradd --root absolute-dirname
- chroot
- edit the files directly

Other thoughts as to things to check....
- expired passwords
- bad character in the password field in /etc/passwd [1]
- something messed-up with PAM - can't help much there

[1] Many years ago I supported a Unix system where suddenly account
passwords weren't working.  IIRC the passwords were set to "*" instead
of "x".  I assume there was an update of some sort and prior to the
update it accepted "*" as "use shadow", but after the update it
insisted on "x".  It was a long time ago, and I may not be remembering
the details correctly.

[Benny Lyne Amorsen]

Meikel  writes:
> Hi folks,
>
> some days ago I did an upgrade of Fedora Xfce from verion 40 to
> version 41. I used the method described in "Upgrading Fedora Linux
> Using DNF System Plugin"
> (https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/).
> To me the last step "sudo dnf system-upgrade reboot" did work
> correctly and then reboot the now updated system. At least I see the
> start screen of version 41. But now I'm no longer able to log into the
> computer, neither via GUI/Xfce nor via console/tty.

It could be an selinux issue. As soon as you change /etc/passwd from a
live media, you will hit it for sure.

Try touch /.autorelabel and maybe /home/.autorelabel as well (under the
appropriate mount point if you do it from live media).

[George N. White III]

On Mon, Nov 18, 2024 at 10:43 AM Meikel  wrote:
> Hi folks,
>
> some days ago I did an upgrade of Fedora Xfce from verion 40 to version
> 41. I used the method described in "Upgrading Fedora Linux Using DNF
> System Plugin"
> (https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/).
>
> To me the last step "sudo dnf system-upgrade reboot" did work correctly
> and then reboot the now updated system. At least I see the start screen
> of version 41. But now I'm no longer able to log into the computer,
> neither via GUI/Xfce nor via console/tty.

I wonder if some glitch left the system in "nologin" state.

From "man nologin":
pam_nologin(8) PAM module usually prevents all non-root users from logging
into the system. pam_nologin(8) functionality is controlled by
/var/run/nologin or the
       /etc/nologin file.

The legacy nologin allowed users to see a message, looks like pam_nologin
may not
advertise that nologin is set.