On 09.07.2012 11:21, Teodor MICU wrote:
2012/7/9 Tollef Fog Heen tfh...@err.no:
I think what might have happened is an aborted upgrade, which I don't
think we currently handle correctly. I'll have to take a look at the
code in question, though.
I think we handle the pam-auth-update bits as
2012/7/9 Michael Biebl bi...@debian.org:
Teodor, could you attach the output of debconf-show libpam-runtime please.
Do you remember editing /etc/pam.d/common-session by hand?
No, I don't think that's the case as showed in a previous message were
a manual execution works properly. The issue is
2012/7/9 Tollef Fog Heen tfh...@err.no:
I think what might have happened is an aborted upgrade, which I don't
think we currently handle correctly. I'll have to take a look at the
code in question, though.
My guess is that this problem was caused by a deadlock in the upgrade.
The packages were
On Tue, Jul 03, 2012 at 12:23:54AM +0200, Michael Biebl wrote:
This is probably from this line in /etc/pam.d/common-session:
| session optionalpam_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
On 09.07.2012 02:54, Steve Langasek wrote:
On Tue, Jul 03, 2012 at 12:23:54AM +0200, Michael Biebl wrote:
Right, the issue is, that we switched to multiarch paths in 44-3.
What does this have to do with multiarch paths? The module path shouldn't
have been embedded in the pam-auth-update
On 03.07.2012 10:17, Teodor MICU wrote:
if [ $1 = remove ] ; then
pam-auth-update --package --remove systemd
fi
Can you please verify?
I don't think this is the case. Executing that command manually works just
fine:
[..]
The problem might be that the above script was not executed on
]] Michael Biebl
What seems to be the problem here is that Teodor has libpam-systemd no
longer installed but there is still a corresponding line in common-session.
I think what might have happened is an aborted upgrade, which I don't
think we currently handle correctly. I'll have to take a
2012/7/2 Tollef Fog Heen tfh...@err.no:
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
Can you please verify?
I
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
]] 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
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):
|
11 matches
Mail list logo
