[systemd-bugs] boot hangs: systemd[1] - nfs branch is not exportable

[Vladimir Elisseev]

Lennart,

After a short discussion in AUFS mailing list, we came to the solution.
I thought it would be useful if I post the answer here as well. The
system could be booted if I disable CONFIG_FHANDLE which is at "General
setup" --> "open by fhandle syscalls". Below is full description of the
problem from AUFS developer.

Regards,
Vlad.

I have took a glance at "encode_fh()" and name_to_handle_at(), and found
that aufs has nothing necessary to support it.
- the protocol around the return code of "encode_fh()" is unchanged.
- aufs already supports name_to_handle_at().

Also I looked at systemd and found the suspicous code around handling
the error of name_to_handle_at().
- systemd calls name_to_handle_at()
- name_to_handle_at() calls aufs's "encode_fh()"
- "encode_fh()" return an error since your branch fs is NFS which
  doesn't support exporting via NFS.
- name_to_handle_at() gets 255 from aufs and returns EOVERFLOW to
  userspace.
  linux/fs/fhandle.c:do_sys_name_to_handle()
        /* we ask for a non connected handle */
        retval = exportfs_encode_fh(path->dentry,
                                    (struct fid *)handle->f_handle,
                                    &handle_dwords,  0);        // which
calls aufs's "encode_fh()"
        :::
        if ((handle->handle_bytes > f_handle.handle_bytes) ||
            (retval == 255) || (retval == -ENOSPC)) {
                /* As per old exportfs_encode_fh documentation
                 * we could return ENOSPC to indicate overflow
                 * But file system returned 255 always. So handle
                 * both the values
                 */
                /*
                 * set the handle size to zero so we copy only
                 * non variable part of the file_handle
                 */
                handle_bytes = 0;
                retval = -EOVERFLOW;
        } else
                retval = 0;
- systemd gets EOVERFLOW from name_to_handle_at(), but it doesn't handle
  this error code.
  systemd/src/shared/path-util.c:path_is_mount_point()
        r = name_to_handle_at(AT_FDCWD, t, h, &mount_id, allow_symlink ?
AT_SYMLINK_FOLLOW : 0);
        if (r < 0) {
                if (errno == ENOSYS || errno == ENOTSUP)
                        /* This kernel or file system does not support
                         * name_to_handle_at(), hence fallback to the
                         * traditional stat() logic */
                        goto fallback;

                if (errno == ENOENT)
                        return 0;

                return -errno;
        }
        :::
        r = name_to_handle_at(AT_FDCWD, parent, h, &mount_id_parent, 0);
        :::
        if (r < 0) {
                /* The parent can't do name_to_handle_at() but the
                 * directory we are interested in can? If so, it must
                 * be a mount point */
                if (errno == ENOTSUP)
                        return 1;

                return -errno;
        }

Although I didn't read the systemd's fallback routine, my current
conclusion is,
- as long as systemd doesn't handle EOVERFLOW (and doesn't go into the
  fallback routine), systemd will not work with many(? a few?) fs, I am
  afraid.
- if systemd support EOVERFLOW, aufs can co-work with systemd. the "nfs
  branch is not exportable" message will be still produced, but systemd
  will go into its fallback routine.
- since systemd has "configure" script and if you disable
  CONFIG_FHANDLE, then systemd will not try calling name_to_handle_at().
  And it will go into the fallback routine. and you will be happy too.


J. R. Okajima




On Tue, 2012-11-20 at 02:28 +0100, Lennart Poettering wrote:
> On Sat, 17.11.12 13:47, Vladimir Elisseev (vovan at vovan.nl) wrote:
> 
> > Hello,
> > 
> > Updating systemd-188 to >=193 leads to boot error: immediately after
> > issuing switch_root systemd hangs with the message "systemd[1] - nfs
> > branch is not exportable", though system can be booted properly if using
> > the SysV init. I've been using AUFS with NFS root (NFS ro with NFS rw
> > branches) for a long while and lately successfully with systemd until
> > got this error. I'd appreciate if somebody can provide an explanation of
> > the reason why this happens.
> 
> Umm, aufs is out of the kernel due to issues. I have no idea really what
> this might be caused by. 
> 
> Maybe this is related to MS_SHARED change? I.e. the default mount
> propagation flag we now set to MS_SHARED rather than MS_PRIVATE, so that
> containers are happy. We encountered numerous issues with that change,
> maybe aufs is another piece in the puzzle that trips over it?
> 
> Lennart
>