 |
VOOZH | about |
|
VOOZH | about |
login with my user or root at the tty would kick me out right away.
login with ssh was working so I looked at the logs while login at tty and this is what I was getting:
===
systemd-coredump[787]: Process 785 (login) of user 1000 dumped core.
===
downgrading systemd fixed the issue.
from
---------------------------
systemd-253.4-1-x86_64
systemd-libs-253.4-1-x86_64
systemd-sysvcompat-253.4-1-x86_64
to
----------------------------
systemd-253.3-3-x86_64
systemd-libs-253.3-3-x86_64
systemd-sysvcompat-253.3-3-x86_64
Offline
got the same issue and have fixed this in this way:
reverted /etc/pam.d/system-auth to its original state
updated systemd
rebooted
re-patched /etc/pam.d/system-auth for pam_ecryptfs in this way
#%PAM-1.0
auth required pam_faillock.so preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth [default=die] pam_faillock.so authfail
auth required pam_ecryptfs.so unwrap
auth optional pam_permit.so
auth required pam_env.so
auth required pam_faillock.so authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.
-account [success=1 default=ignore] pam_systemd_home.so
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so
password optional pam_ecryptfs.so
-password [success=1 default=ignore] pam_systemd_home.so
password required pam_unix.so try_first_pass nullok shadow sha512
password optional pam_permit.so
-session optional pam_systemd_home.so
session required pam_limits.so
session required pam_unix.so
session [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
session optional pam_ecryptfs.so unwrap
session optional pam_permit.soLast edited by akrone (2023-05-07 11:46:00)
Offline
I just ran into this issue today, and downgrading indeed worked for me.
akrone, I don't understand what you reverted in the config, can you expand which entry was causing the core dump in the login process?
Offline
Updating systemd brought me in the same error situation as described above. And I came across this topic on my search for a solution.
That only two persons are faced with this same error let me think: have a look on your own changes, might be the reason is on your side.
I had applied some patches in system-auth regarding ecryptfs.
My simple solution was to re-install pambase, this brought system-auth back into its original state.
After a full upgrade login worked flawlessly.
$pacman -S pambase
$pacman -SyuOffline
Same here, also using ecryptfs. I have patched my /etc/pam.d/system-auth and noticed a system-auth.pacnew dating back to 2022, so i guess the file wasn't updates as intended during the update due to my changes.
I followed the instructions above and it worked well, did a diff afterwards, there are two changed regarding systmd-homed:
auth [success=2 default=ignore] pam_unix.so try_first_pass nullok
-auth [success=1 default=ignore] pam_systemd_home.sobecame
-auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullokand the line
-session optional pam_systemd_home.sogot added.
Offline
I found a fix, at least for my system:
I ended up commenting out all the pam_systemd_home.so lines, and then restarting the login process from an SSH connection.
These were the lines I changed to comments in the /etc/pam.d/system-auth file:
#-auth [success=1 default=ignore] pam_systemd_home.so
#-account [success=1 default=ignore] pam_systemd_home.so
#-password [success=1 default=ignore] pam_systemd_home.soThe I restarted the TTY process with this to pick up the changes.
sudo systemctl restart getty@tty1Note, I also have auditing enabled on my TTYs, I commented this out, but then re-enabled it, I don't think this was the cause, but just thought I would mention it.
session required pam_tty_audit.so enable=*After these changes I can now login on the latest systemd version (253.4-1).
Offline
The pam_systemd_home.so all start with a - meaning if the file is not present the entry will be skipped so you should be able to add usr/lib/security/pam_systemd_home.so as a NoExtract extract entry in pacman.conf reinstall systemd and achieve the same result without changing any pam configs.
Please also consider opening a bug upstream to systemd see also https://bugs.archlinux.org/task/77435
Offline
Powered by FluxBB