Cannot umount /proc after using update-binfmts in a chroot

[Alkis Georgopoulos]

Binary package hint: binfmt-support

As part of LTSP fat client installations, the following instructions are performed (cut down version):

$ chroot "$ROOT" mount -t proc proc /proc
$ chroot "$ROOT" update-binfmts --import wine
$ umount "$ROOT/proc"

At this point we get:
$ umount: /opt/ltsp/i386/proc: device is busy.
$ (In some cases useful info about processes that use
$ the device is found by lsof(8) or fuser(1))
...and we're forced to resort to `umount -l` to work around this problem.

Is the any way to call update-binfmts in a chroot (e.g. to install wine) without having to resort to `umount -l`?

[Alkis Georgopoulos (alkisg)]

If, before calling `umount "$ROOT/proc"`, I run:
$ chroot "$ROOT" invoke-rc.d binfmt-support stop
then umount works cleanly.

BUT I'm losing "cli" and "wine" from /proc/sys/fs/binfmt_misc/ on the *real* fs tree, so I then have to run
$ invoke-rc.d binfmt-support start
on the real tree to get them back... so I don't think that qualifies as an acceptable solution.

Would it be possible to completely divert update-binfmts in the chroot (and replace it with `true`), and still have everything working properly?
I.e. is the update-binfmts call in wine1.2.postinst (and in the java postinst etc) required, or is putting the "cli", "jar", "wine" etc files in /usr/share/binfmts enough?

[Alkis Georgopoulos (alkisg)]

I'm attaching the output of a trace, in case it helps.

$ perl -w -d:Trace /usr/sbin/update-binfmts --import wine

[Oliver Grawert (ogra)]

this is not a bug, its expected behavior. the kernel binfmt handler works through the virtual binfmt_misc filesystem. since both proc filesystems you use (the chroot and the host one) are identical your bnfmt handler of the host gets disabled if you disable the one inside the chroot. the only proper solution here would be to have an emulated proc inside the chroot. probably have a look at linux containers for this.

[Colin Watson (cjwatson)]

The workaround for the unmounting problem is to umount /proc/sys/fs/binfmt_misc, and right now there's no workaround for the overlapping binfmt namespaces, but I'm not sure that this isn't a bug anyway, even if it's hard to solve.

[Alkis Georgopoulos (alkisg)]

A workaround for LTSP was committed in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/1704.

[Alkis Georgopoulos (alkisg)]

Fix released in LTSP 5.2.1.

[Launchpad Janitor (janitor)]

This bug was fixed in the package binfmt-support - 2.2.0-1

---------------
binfmt-support (2.2.0-1) unstable; urgency=medium

  * New upstream release.
    - Sort formats by name in the output of "update-binfmts --display".
    - Add a new --unimport action, which is the inverse of --import.
    - Don't enable formats on import or disable them on unimport unless
      /proc/sys/fs/binfmt_misc is already mounted. This avoids causing
      cleanup problems in chroots (closes: #847788, LP: #534211).
    - "--fix-binary yes" is incompatible with detectors. Warn the user if
      they try to use both at once (closes: #918901).
  * Document recommended maintainer script use of --unimport in
    README.Debian.
  * Stop building with V=1; debhelper configures with --disable-silent-rules
    as of 9.20150501.

 -- Colin Watson <email address hidden> Fri, 25 Jan 2019 00:25:54 +0000