mount-image-callback may not mount overlay when it could

[Scott Moser]

The changes recently added to mount-image-callback under bug 1493188 that were targeted at supporting 'overlay' filesystem type while still supporting 'overlayfs' may result in exiting with "unsupported" when a mount would work.

The changes basically said:
  if overlay in /proc/filesystems:
     return GOOD
  modprobe --quiet --use-blacklist overlay
     if overlay in /proc/filesystems:
        return GOOD
  return BAD

the path that fails now that previously succeeded is when 'modprobe' would not work, but 'mount -t overlay' *would*. This occurs in build systems where the running kernel is of one version and code is running in a chroot that does not have access to the kernel modules in /lib/modules/.

'mount -t overlay' works in this scenario because the mount abi call passes the filesystem type 'overlay', and the kernel then does:
   fs/filesystems.c: if (!fs && (request_module("fs-%.*s", len, name) == 0))

The kernel's scope is not chrooted, so the module gets loaded and everything is happy.

The new changes are to instead basically do:
  for fstype in overlay overlayfs; do
     mount -t $fstype <options> && return GOOD
     if /proc/filesystems is readable and $fstype in /proc/filesystems; then
         return FAIL
     fi
  done

[Scott Moser (smoser)]

marked this as critical, as it is blocking maas image builds for 16.10.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cloud-utils - 0.29-0ubuntu5

---------------
cloud-utils (0.29-0ubuntu5) yakkety; urgency=medium

  * debian/control: update to Standards-Version 3.9.8
  * debian/copyright: fix lintian file-without-copyright-information.
  * sync to trunk at revno 306
    * mount-image-callback: try mounting overlay rather than checking first
      (LP: #1630274)

 -- Scott Moser <email address hidden> Tue, 04 Oct 2016 12:36:21 -0400