Debugging per [1], did not show anything new.
There just is no activity on the actual access of /home all I see is the
trigger for /home registering at startup.
Startup:
ubuntu@xenial-autofs-client:/$ sudo automount -f -v --debug
Starting automounter version 5.1.1, master map /etc/auto.master
using kernel protocol version 5.02
lookup_nss_read_master: reading master file /etc/auto.master
parse_init: parse(sun): init gathered global options: (null)
lookup_read_master: lookup(file): read entry +dir:/etc/auto.master.d
lookup_nss_read_master: reading master dir /etc/auto.master.d
lookup_read_master: lookup(dir): scandir: /etc/auto.master.d
lookup_read_master: lookup(file): read entry /-
master_do_mount: mounting /-
automount_path_to_fifo: fifo name /var/run/autofs.fifo--
lookup_nss_read_map: reading map file /etc/auto.nfs
parse_init: parse(sun): init gathered global options:
nosymlink,fstype=nfs,nfsvers=3,rw,hard,intr,rsize=8192,wsize=8192
mounted direct on /home with timeouts disabled
do_mount_autofs_direct: mounted trigger /home
st_ready: st_ready(): state = 0 path /-
It is the open syscall itself that fails:
0.000029 open("/home", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ELOOP
(Too many levels of symbolic links) <0.000012>
So we must have set up the kernel/trigger to be broken - no userspace component
active at the time (although it might have set it up wrong before).
But since I haven't found fixes in autofs maybe it is fixed in the kernel then?
Yes, here I found a fix.
Installing linux-virtual-hwe-16.04 (since I was in a VM to test) resolved the
issue.
With the same setup I can now mount /home just fine again on Xenial.
On a bare metal system you likely want linux-generic-hwe-16.04 instead.
I'm adding a kernel task to potentially identify and backport the fix to the
4.4 kernel, but since after so much time it isn't in the stable releases
chances are that it is hard to backport.
Until then you can get this issue resolved with the -hwe kernels.
[1]:
https://help.ubuntu.com/community/Autofs#Debugging_Auto_Mount_Problems
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: autofs5 (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: autofs5 (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: autofs5 (Ubuntu Bionic)
Status: New => Invalid
** Changed in: autofs5 (Ubuntu Xenial)
Status: New => Invalid
** Changed in: autofs5 (Ubuntu)
Status: Confirmed => Invalid
** Changed in: linux (Ubuntu)
Status: New => Fix Released
** Changed in: linux (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: linux (Ubuntu Bionic)
Status: New => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title:
autofs - "Too many levels of symbolic links" after apt upgrade
Status in autofs5 package in Ubuntu:
Invalid
Status in linux package in Ubuntu:
Fix Released
Status in autofs5 source package in Xenial:
Invalid
Status in linux source package in Xenial:
Confirmed
Status in autofs5 source package in Bionic:
Invalid
Status in linux source package in Bionic:
Fix Released
Bug description:
Description: Ubuntu 16.04.6 LTS
Release: 16.04
I moved to autofs this week as a workaround for Bug #1577575 failing
to mount NFS entries at boot. This worked file until I ran 'apt
upgrade' today.
Now trying to access /vol/home mount results in the following error:
root@chi:~# ls -la /vol/home/
ls: cannot access '/vol/home/': Too many levels of symbolic links
root@chi:~#
Oddly enough, the other two autofs entries work fine (output trimmed):
root@chi:~# ls -la /vol/media
total 4
...
root@chi:~#
root@chi:~# ls -al /vol/temp/
total 24
...
root@chi:~#
I have a scratch VM I can break tonight by performing upgrades individually
and testing after each. Will provide that detail when available.
Here is /var/log/apt/history.log
Start-Date: 2019-05-01 17:37:00
Commandline: apt upgrade
Upgrade: libdns-export162:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), libisccfg140:amd64
(1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14), ureadahead:amd64
(0.100.0-19, 0.100.0-19.1), libldap-2.4-2:amd64 (2.4.42+dfsg-2ubuntu3.4,
2.4.42+dfsg-2ubuntu3.5), libirs141:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), bind9-host:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), dnsutils:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), libisc160:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), passwd:amd64 (1:4.2-3.1ubuntu5.3,
1:4.2-3.1ubuntu5.4), bind9utils:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), libisc-export160:amd64
(1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14), liblwres141:amd64
(1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14), login:amd64
(1:4.2-3.1ubuntu5.3, 1:4.2-3.1ubuntu5.4), iproute2:amd64
(4.3.0-1ubuntu3.16.04.4, 4.3.0-1ubuntu3.16.04.5), bind9:amd64
(1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14), libdns162:amd64
(1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14),
unattended-upgrades:amd64 (0.90ubuntu0.10, 1.1ubuntu1.18.04.7~16.04.2),
libisccc140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12, 1:9.10.3.dfsg.P4-8ubuntu1.14),
libbind9-140:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), uidmap:amd64 (1:4.2-3.1ubuntu5.3,
1:4.2-3.1ubuntu5.4), bind9-doc:amd64 (1:9.10.3.dfsg.P4-8ubuntu1.12,
1:9.10.3.dfsg.P4-8ubuntu1.14), tzdata:amd64 (2018i-0ubuntu0.16.04,
2019a-0ubuntu0.16.04)
End-Date: 2019-05-01 17:37:24
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
