[Bug 1438942] Re: Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots

Michał Sawicz michal.sawicz at canonical.com
Tue May 12 17:50:11 UTC 2015


Yeah it seems the default fstab from sbuild includes /dev/shm. Talk to
mterry about the home issue, he's had it I believe.

** Also affects: sbuild (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to schroot in Ubuntu.
https://bugs.launchpad.net/bugs/1438942

Title:
  Host's /dev/shm is mounted over when entering 14.10 and older sbuild
  schroots

Status in sbuild package in Ubuntu:
  New
Status in schroot package in Ubuntu:
  Confirmed

Bug description:
  Originally reported by Scott Moser:

  https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264/comments/12

  On a Vivid system with schroot 1.6.10-1ubuntu1, the host's /dev/shm is
  mounted over with a new tmpfs instance when entering a 14.10 and older
  schroot. It does not happen when entering a Vivid schroot.

  # Create 14.10 and Vivid sbuild schroots
  $ arch=amd64
  $ for rel in vivid utopic; do mk-sbuild --eatmydata --arch=$arch $rel 2>&1 | tee /tmp/schroot-$rel-$arch.log; done

  # Enter vivid-amd64 sbuild schroot and diff /proc/self/mounts
  $ mounts=/proc/self/mounts
  $ orig=$(mktemp) && cp $mounts $orig && schroot -c vivid-amd64 true; diff -u $orig $mounts

  # Enter utopic-amd64 sbuild schroot and diff /proc/self/mounts
  $ orig=$(mktemp) && cp $mounts $orig && schroot -c utopic-amd64 true; diff -u $orig $mounts
  --- /tmp/tmp.DdnrDnkS2B	2015-03-31 18:19:51.406526006 -0500
  +++ /proc/self/mounts	2015-03-31 18:19:51.818526006 -0500
  @@ -28,3 +28,4 @@
   tmpfs /run/user/108 tmpfs rw,nosuid,nodev,relatime,size=101688k,mode=700,uid=108,gid=117 0 0
   gvfsd-fuse /run/user/108/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=108,group_id=117 0 0
   tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=101688k,mode=700,uid=1000,gid=1000 0 0
  +tmpfs /dev/shm tmpfs rw,relatime 0 0

  # Verify that /proc/self/mounts now contains two /dev/shm mounts
  $ grep /dev/shm $mounts
  tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
  tmpfs /dev/shm tmpfs rw,relatime 0 0

  This causes a problem for programs that keep state in /dev/shm. For
  example, ecryptfs-utils maintains a per-user session counter in
  /dev/shm that is lost when a new tmpfs mount is performed on top of
  the old tmpfs mount. This results in encrypted home directories being
  unmounted when the schroot is tore down.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1438942/+subscriptions



More information about the foundations-bugs mailing list