NFS mount binary missing in base-64-lts

[hadret]

Hello,
today I've encountered problem with mounting NFS share inside the Zone. Here's truss if the problem:

truss /sbin/mount /nfs
execve("/sbin/mount", 0x08047D84, 0x08047D90)  argc = 2
sysinfo(SI_MACHINE, "i86pc", 257)               = 6
mmap(0x00000000, 32, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFB0000
sysconfig(_CONFIG_PAGESIZE)                     = 4096
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEFA0000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF90000
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEF80000
memcntl(0xFEFB5000, 49388, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
memcntl(0x08050000, 8848, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
resolvepath("/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
resolvepath("/sbin/mount", "/sbin/mount", 1023) = 11
stat64("/sbin/mount", 0x08047A18)               = 0
open("/var/ld/ld.config", O_RDONLY)             = 3
fstat64(3, 0x08047598)                          = 0
mmap(0x00000000, 140, PROT_READ, MAP_SHARED, 3, 0) = 0xFEF70000
close(3)                                        = 0
stat64("/lib/libc.so.1", 0x08047238)            = 0
resolvepath("/lib/libc.so.1", "/lib/libc.so.1", 1023) = 14
open("/lib/libc.so.1", O_RDONLY)                = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFEF80B58, 0x080472A4, 0x00000000) = 0
close(3)                                        = 0
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEE00000
memcntl(0xFEE10000, 251428, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
mmap(0x00010000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDF0000
getcontext(0x08047858)
getrlimit(RLIMIT_STACK, 0x08047850)             = 0
getpid()                                        = 71887 [71886]
lwp_private(0, 1, 0xFEDF2A40)                   = 0x000001C3
setustack(0xFEDF2AA0)
lwp_cond_broadcast(0xFEE000FC)                  = 0
lwp_cond_broadcast(0xFEF8062C)                  = 0
sysi86(SI86FPSTART, 0xFEF62E2C, 0x0000133F, 0x00001F80) = 0x00000001
sysconfig(_CONFIG_PAGESIZE)                     = 4096
open("/usr/lib/locale//en_US.UTF-8/LC_CTYPE/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x080475E8)                            = 0
mmap(0x00000000, 94904, PROT_READ, MAP_PRIVATE, 3, 0) = 0xFEDD7000
close(3)                                        = 0
mmap(0x00010000, 131072, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDB0000
munmap(0xFEDD7000, 94904)                       = 0
open("/usr/lib/locale//en_US.UTF-8/LC_NUMERIC/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047608)                            = 0
read(3, " .\n ,\n 3\n", 6)                      = 6
close(3)                                        = 0
open("/usr/lib/locale//en_US.UTF-8/LC_TIME/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047608)                            = 0
read(3, " J a n\n F e b\n M a r\n".., 308)      = 308
close(3)                                        = 0
open("/usr/lib/locale//en_US.UTF-8/LC_COLLATE/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047648)                            = 0
mmap(0x00000000, 75408, PROT_READ, MAP_PRIVATE, 3, 0) = 0xFEDDC000
close(3)                                        = 0
open("/usr/lib/locale//en_US.UTF-8/LC_MONETARY/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x080475F8)                            = 0
read(3, " U S D  \n $\n .\n ,\n 3".., 44)       = 44
close(3)                                        = 0
open("/usr/lib/locale//en_US.UTF-8/LC_MESSAGES/LCL_DATA", O_RDONLY) = 3
fstat(3, 0x08047608)                            = 0
read(3, " ^ ( ( [ y Y ] ( [ e E ]".., 45)       = 45
close(3)                                        = 0
brk(0x08067280)                                 = 0
brk(0x08069280)                                 = 0
open("/etc/vfstab", O_RDONLY)                   = 3
llseek(3, 0, SEEK_CUR)                          = 0
fstat64(3, 0x080479B0)                          = 0
fstat64(3, 0x080478B0)                          = 0
ioctl(3, TCGETA, 0x0804796E)                    Err#25 ENOTTY
read(3, " # d e v i c e          ".., 1024)     = 749
llseek(3, 0, SEEK_CUR)                          = 749
close(3)                                        = 0
resolvepath("/nfs", "/nfs", 1024)               = 4
stat64("/nfs", 0x08047B60)                      = 0
access("/usr/lib/fs/nfs/mount", F_OK)           Err#90 ELOOP
execve("/etc/fs/nfs/mount", 0x08047CF4, 0x08047D90) Err#90 ELOOP
open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/SUNW_OST_OSCMD.mo", O_RDONLY) Err#2 ENOENT
fstat64(2, 0x08046440)                          = 0
mountwrite(2, " m o u n t", 5)                  = 5
: Operation not applicable to FSType write(2, " :   O p e r a t i o n  ".., 37) = 37
nfs
write(2, " n f s\n", 4)                         = 4
_exit(1)

I had older Zone mounting NFS share without any issue, so I went on to check binary placement. Here's the problem:

ls -l /etc/fs/nfs/mount
lrwxrwxrwx 1 root root 29 Feb 27 15:50 /etc/fs/nfs/mount -> ../../../usr/lib/fs/nfs/mount

ls -l /usr/lib/fs/nfs/mount
lrwxrwxrwx 1 root root 28 Oct 30 19:59 /usr/lib/fs/nfs/mount -> ../../../../etc/fs/nfs/mount

So:

/usr/lib/fs/nfs/mount /nfs
-bash: /usr/lib/fs/nfs/mount: Number of symbolic links encountered during path name traversal exceeds MAXSYMLINKS

For anyone also hit by that issue -- autofs may serve you as a temporary workaround:

svcadm enable autofs
cd /net/$IP_ADDRESS_OF_THE_SERVER/$MOUNTPOINT

All the best!

[rmustacc]

What's the output of uname -v here and can you include the JSON file you used to provision this?

[jjelinek]

This changed with https://smartos.org/bugview/OS-3792 however it looks like you somehow have gotten into a state where you are using a zone created with a new etc directory on an older platform which predates this change. The latest platform delivers usr/lib/fs/nfs/mount as a file but your bug report shows you are running with an old /usr. Can you clarify where/how your zone root directory was created and if you are somehow using a zone created with an image from after OS-3792 on an old platform?

[hadret]

What's the output of uname -v here and can you include the JSON file you used to provision this?

uname -v
joyent_20141030T164802Z

And here's the json file:

{
  "brand": "joyent",
  "image_uuid": "c02a2044-c1bd-11e4-bd8c-dfc1db8b0182",
  "autoboot": false,
  "alias": "08-wpms",
  "hostname": "wpms.fq.dn",
  "resolvers": [
    "8.8.8.8",
    "8.8.4.4"
  ],
  "max_physical_memory": 1024,
  "max_swap": 1024,
  "quota": 10,
  "nics": [
    {
      "nic_tag": "admin",
      "mac": "02:00:00:xx:xx:xx",
      "ip": "176.xx.xx.xx",
      "netmask": "255.255.255.255",
      "gateway": "176.xx.xx.xx",
      "primary": true,
      "allow_ip_spoofing": true,
      "allow_mac_spoofing": true
    },
    {
      "nic_tag": "lan",
      "ip": "10.0.0.8",
      "netmask": "255.255.255.0"
    }
  ]
}

Can you clarify where/how your zone root directory was created and if you are somehow using a zone created with an image from after OS-3792 on an old platform?

Is 20141030T164802Z considered old?

[jperkin]

This is a minor bug in the 14.4.0 images, as we have shipped an /etc which is newer than the min_platform that we have defined for those images. We will deliver an updated set of 14.4.1 images over the next few weeks which will address this, and from then on ensure that /etc matches min_platform.

Until then, either use the workarounds listed above or use a platform which includes https://smartos.org/bugview/OS-3792.

Thanks, and sorry for the breakage.

[dwlf]

@jperkin excuse my ignorance, what is the min_platform here? Is that information embedded in the image? -- what command do I run? Should we also include it at https://docs.joyent.com/images/smartos/base#base-14.4.0 ?

[jperkin]

The min_platform is:

# imgadm show c02a2044-c1bd-11e4-bd8c-dfc1db8b0182 | json requirements.min_platform
{
  "7.0": "20141030T081701Z"
}

and yes, we should probably include it in the documentation.

[dwlf]

@jperkin thnx, I'll open a doc bug.

[dwlf]

@hadret thanks for identifying this issue and sorry for the inconvenience.

I'll close this issue for now:

• 14.4.1 will be replaced in the next few weeks.
• PI with TritonDataCenter/illumos-joyent@d5fef2f , newer than Feb 3, 2015.
• workaround like one described above by @hadret, "autofs".