bin/49601: amd(8) no longer works, at least in LDAP mode

[tron%zhadum.org.uk@localhost]

>Number:         49601
>Category:       bin
>Synopsis:       amd(8) no longer works, at least in LDAP mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 24 14:05:00 +0000 2015
>Originator:     Matthias Scheler
>Release:        NetBSD 7.99.4 sources from HEAD as 2015-01-24 8:00 UTC
>Organization:
Matthias Scheler                                 https://zhadum.org.uk/
>Environment:
System: NetBSD lyssa.zhadum.org.uk 7.99.4 NetBSD 7.99.4 (GENERIC) #0: Sat Jan 24 13:37:20 GMT 2015  tron%lyssa.zhadum.org.uk@localhost:/src/sys/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
After upgrading my NetBSD/amd64 current VM from a 2015-01-14 to 2015-01-24
sources amd(8) doesn't come up when the machine boots. It logs the
following error message via syslog(3):


>How-To-Repeat:
Try to use amd(8) configured to use LDAP as the directory service.
My "/etc/amd.conf" looks like this:

Jan 24 13:45:17 lyssa amd[517]: failed to initialize map amd.share
Jan 24 13:45:17 lyssa amd[517]: No source data for map amd.share
Jan 24 13:48:28 lyssa /netbsd: kern.module.path=/stand/amd64/7.99.4/modules
Jan 24 13:48:35 lyssa amd[517]: failed to initialize map amd.share
Jan 24 13:48:35 lyssa amd[517]: No source data for map amd.share

Any access to an amd(8) auto-mounted directory just hangs:

root@lyssa:~#cd /home/tron &
[1] 2039
root@lyssa:~#jobs
[1]  + running    cd /home/tron

[global]
auto_attrcache     = 1
ldap_base          = dc=zhadum,dc=org,dc=uk
ldap_hostports     = zhadum.org.uk
ldap_proto_version = 3
nfs_proto          = udp
search_path        = /etc/amd
unmount_on_exit    = yes

[ /home ]
map_name =      amd.home
map_type =      ldap

[ /share ]
map_name =      amd.share
map_type =      ldap

[ /scratch ]
map_name =      amd.scratch
map_type =      ldap

[ /volumes ]
map_name =      volumes
map_type =      file

>Fix:
Reverting my machine to the previous current build fixes the problem.
My Mac OS X NFS client also shows no LDAP problem. This probably rules
out a problem with the LDAP/NFS server.