On 02.07.2012 17:39, Tollef Fog Heen wrote: > ]] Teodor > >> Package: systemd >> Version: PAM adding faulty module: pam_systemd.so >> Severity: normal >> >> After packages removal I get these on syslog: >> | Jul 2 15:05:01 frost CRON[7633]: PAM unable to dlopen(pam_systemd.so): >> | /lib/security/pam_systemd.so: cannot open shared object file: No such >> | file or directory >> | Jul 2 15:05:01 frost CRON[7633]: PAM adding faulty module: pam_systemd.so >> >> This is probably from this line in /etc/pam.d/common-session: >> | session optional pam_systemd.so > > I suspect you have told pam that you want to manage common-session by > hand, else this is a bug in pam-auth-update, since the postinst just > says: > > if [ "$1" = "remove" ] ; then > pam-auth-update --package --remove systemd > fi
Right, the issue is, that we switched to multiarch paths in 44-3. I think pam-auth-update should handle that correctly, i.e. update the paths in the pam configuration even if the pam-configs snippet hasn't changed. Steve, can you confirm that this should work? Is there an easy way to check if the pam configuration is managed manually and not by pam-auth-update? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
