jdk9 builds failing with: java.io.IOException: Mount point not found

[Matthias Klose]

In some build environments jdk9 builds fail with

Error: jdk.tools.jlink.plugin.PluginException: java.io.IOException: Mount point
not found

complete build log e.g. at
https://launchpadlibrarian.net/281693434/buildlog_ubuntu-yakkety-arm64.openjdk-9_9~b133-1ubuntu1_BUILDING.txt.gz

The issue is not new, popped up earlier as seen in
http://mail.openjdk.java.net/pipermail/nio-dev/2009-May/000547.html

However for some reason this code is not called during 7 and 8 builds, only for 9.

The problem is that LinuxFileStore.findMountEntry() tries to look up the file
system by looking up /etc/mtab (which doesn't exist), and then trying to look up
/proc/mounts which only has:

$ cat /proc/mounts
none /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
none /sys sysfs rw,relatime 0 0
none /dev/shm tmpfs rw,relatime 0 0

it's about the entry for the top of the chroot fs namespace is missing.

You can reproduce this with a 3.19 or newer kernel by taking a random chroot and
doing "sudo mount -t proc none $CHROOT/proc; sudo chroot $CHROOT cat
/proc/mounts; sudo umount $CHROOT/proc"

Maybe this worked in 2009, but apparently due to a kernel change in 2014, this
entry for the top of the chroot namespace is not always visible:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d4d65748a5ca26ea8650e50ba521295549bf4e3

The alternative would be to use the f_fsid field in the the statvfs information
to get a handle for the file system / the file storage.

$ sudo mount -t proc none /var/lib/schroot/chroots/xenial-amd64/proc; sudo
chroot /var/lib/schroot/chroots/xenial-amd64 stat -f /bin/ls; sudo umount
/var/lib/schroot/chroots/xenial-amd64/proc
  File: "/bin/ls"
    ID: ee43128f92e561ac Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 113075671  Free: 10105058   Available: 4355386
Inodes: Total: 28729344   Free: 21572152


As a work around, is it possible to disable this check as it's done for OpenJDK-8?

Matthias