With autofs-5.1.1-r1 NFS mount fails. Message is: no hosts autofs-5.1.1 is working.
I can confirm this. handle_packet: type = 3 handle_packet_missing_indirect: token 32, name portage, request pid 5318 attempting to mount entry /srv/portage lookup_mount: lookup(file): looking up portage lookup_mount: lookup(file): portage -> -fstype=nfs,vers=4,rw 1.2.3.4:/portage parse_mount: parse(sun): expanded entry: -fstype=nfs,vers=4,rw 1.2.3.4:/portage parse_mount: parse(sun): gathered options: fstype=nfs,vers=4,rw parse_mount: parse(sun): dequote("1.2.3.4:/portage") -> 1.2.3.4:/portage parse_mount: parse(sun): core of entry: options=fstype=nfs,vers=4,rw, loc=1.2.3.4:/portage sun_mount: parse(sun): mounting root /srv, mountpoint portage, what 1.2.3.4:/portage, fstype nfs, options vers=4,rw mount_mount: mount(nfs): root=/srv name=portage what=1.2.3.4:/portage, fstype=nfs, options=vers=4,rw mount_mount: mount(nfs): nfs options="vers=4,rw", nobind=0, nosymlink=0, ro=0 get_nfs_info: called with host 1.2.3.4(1.2.3.4) proto 6 version 0x40 mount(nfs): no hosts available dev_ioctl_send_fail: token = 32 failed to mount /srv/portage st_readmap: state 1 path /srv handle_packet: type = 3 handle_packet_missing_indirect: token 33, name portage, request pid 5318 dev_ioctl_send_fail: token = 33 re-reading map for /srv lookup_nss_read_map: reading map file /etc/autofs/auto.srv do_init: parse(sun): init gathered global options: (null) st_ready: st_ready(): state = 4 path /srv
Does use_hostname_for_mounts = "yes" in autofs.conf fix this? I think I was seeing the same for a an NFS server with A and AAAA records.
Have tested it. It was failing without use_hostname_for_mounts = "yes" and resolved by implementing it into the configuration file. So i can confirm, that this configuration setting helps. But it would be very good, to have a notification at the end of the installation step.
I think this is the patch that introduces this option: https://www.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.2/autofs-5.1.1-add-configuration-option-to-use-hostname-in-mounts.patch My interpretation about what this is supposed to do and given the behaviour observed I suspect that there is an issue with this.
(In reply to Spooky Ghost from comment #4) > I think this is the patch that introduces this option: > > https://www.kernel.org/pub/linux/daemons/autofs/v5/patches-5.1.2/autofs-5.1. > 1-add-configuration-option-to-use-hostname-in-mounts.patch > > My interpretation about what this is supposed to do and given the behaviour > observed I suspect that there is an issue with this. Indeed, thanks for hunting this down.. Btw, would a einfo or README.gentoo (in pkg_postinst) help?
(In reply to Spooky Ghost from comment #2) > Does use_hostname_for_mounts = "yes" in autofs.conf fix this? I think I was > seeing the same for a an NFS server with A and AAAA records. Solved my problem, too. I updated from v5.0.7-r4 to 5.1.1-r1 today and found that I can't access my Synology NAS any more. automounter crashed with a segfault when a normal user tried to access an exported folder from NAS: Jun 18 10:56:06 frodo kernel: automount[11486]: segfault at 0 ip (null) sp 00007fbc609fbba8 error 14 in automount[562252fc5000+47000] Adding hostname_for_mounts = "yes" in autofs.conf and restarting autofs solved my issues.
I think autofs 5.1.2 has this fixed, can someone else confirm?
(In reply to Matthew Thode ( prometheanfire ) from comment #7) > I think autofs 5.1.2 has this fixed, can someone else confirm? 5.1.2 works for me while 5.1.1-r1 did not.
(In reply to Matthew Thode ( prometheanfire ) from comment #7) > I think autofs 5.1.2 has this fixed, can someone else confirm? Yes, works for me using the same configuration (autofs.conf) as with v5.0.7 (hostname_for_mounts disabled).
