Here is a patch which summarized this discussion. I've tested this on a
number of systems and it satisfactorily fixes the "doesn't boot" problem.
Note to -release: This needs the initscripts version from unstable, which is
frozen.
diff -u libnss-ldap-251/debian/changelog libnss-ldap-251/debian/
reopen 375077
thanks bts
Hello,
udev 0.100-2
libnss-ldap 251-5.2
When I upgrade to libnss-ldap 251-5.2, old init script links are
always here and then with bad sequence numbers. Indeed,
update-rc.d in postinst failed with :
System startup links for /etc/init.d/libnss-ldap already exist.
Here i
Hi,
I think that I know why some people still see this bug and have reopened
it.
The fix implemented by Stephen (thanks BTW!) is documented
in /var/lib/dpkg/info/libnss-ldap.postinst :
# The /var/lib/libnss-ldap directory is used for one purpose:
# to provide a place to store the 'bind_policy_so
I have exactly the same bug. A friend of mine who uses Gentoo has this bug
after the latest update too, so I think it is a bug in the upstream package,
because the changed the bind_policy.
I have found a little workaround to be able to boot the system again:
Add the following lines to your /etc
Package: libnss-ldap
Version: 251-1
Severity: grave
To relevant parts of nsswitch.conf on my system look like this:
passwd:files ldap
group: files ldap
shadow:files ldap
libnss_ldap is configured to query a remote LDAP server.
This makes booting stuck if you use udevd (wh
5 matches
Mail list logo