touch-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

Directories in a pristine trusty VM after debootstrapping utopic and
vivid:

$ ls -ld /{dev,run}/shm /tmp/{utopic,vivid}/{dev,run}/shm
ls: cannot access /tmp/vivid/run/shm: No such file or directory
lrwxrwxrwx 1 root root    8 Dec 18 18:37 /dev/shm -> /run/shm
drwxrwxrwt 2 root root   40 Dec 18 18:37 /run/shm
lrwxrwxrwx 1 root root    8 Dec 18 18:49 /tmp/utopic/dev/shm -> /run/shm
drwxr-xr-x 2 root root 4096 Dec 18 18:49 /tmp/utopic/run/shm
drwxr-xr-x 2 root root 4096 Dec 18 18:50 /tmp/vivid/dev/shm

So I suppose pbuilder takes care of /run/shm by mounting a tmpfs on it
or bind-mounting it from the host. As wrong as
https://wiki.debian.org/ReleaseGoals/RunDirectory is (and it seems the
Debian sysvinit maintainers even have moved away from it, cf. the
removed postinst code), it seems we need to go back there at least half
way, until pbuilder etc. treat /dev/shm/ as the primary thing, and stop
using /run/shm.

So either in vivid we need to create /run/shm/ again and the /dev/shm
symlink to it, or at least make /dev/shm/ 1777.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sysvinit in Ubuntu.
https://bugs.launchpad.net/bugs/1399772

Title:
  /dev/shm is not writable inside vivid chroot on trusty host

Status in sysvinit package in Ubuntu:
  In Progress

Bug description:
  This problem is visible on a pool of pbuilder nodes. All of the slaves
  are amd64 running trusty. I can observe the issue when using pbuilder
  to mount a vivid chroot. The problem can be recognized by the fact
  that within the chroot, /dev/shm is not a link to /run/shm. See output
  below. This problem is only visible on a set of x86 hosts. I also have
  a set of armhf hosts (with armhf chroots). These armhf boxes do not
  show the problem.

  This is only visible with vivid chroots. Trusty and utopic chroots
  show /dev/shm as a symlink to /run/shm.

  All of the hosts have debootstrap 1.0.59ubuntu0.2. The amd64 nodes are
  running in openstack VMs, the armhf nodes are running on bare metal.

  This appears to be a regression in behavior. The problem is impacting
  unit test cases in packages being built with the chroots. These test
  were working in the past, but the exact timeframe for when the problem
  was first observed is difficult to track down. Possible this has only
  been the case for about 2 months.

  
  [On the amd64 host:]
  $ ls -la /{dev,run}/sh*
  lrwxrwxrwx 1 root root  8 Nov 26 21:15 /dev/shm -> /run/shm

  /run/shm:
  total 0
  drwxrwxrwt  2 root root  40 Nov 26 21:19 .
  drwxr-xr-x 21 root root 800 Dec  5 17:38 ..

  [Inside the amd64 chroot:]
  # ls -la /{dev,run}/sh*
  /dev/shm:
  total 8
  drwxr-xr-x 2 root root 4096 Nov 26 21:31 .
  drwxr-xr-x 4 root root 4096 Nov 26 21:31 ..

  /run/shm:
  total 4
  drwxrwxrwt 2 root root   40 Dec  5 19:16 .
  drwxr-xr-x 5 root root 4096 Nov 26 21:32 ..

  [On the armhf host:]
  $ ls -la /{dev,run}/sh*
  lrwxrwxrwx 1 root root  8 Aug  9 05:08 /dev/shm -> /run/shm

  /run/shm:
  total 0
  drwxrwxrwt  2 root root  40 Aug  9 05:08 .
  drwxr-xr-x 17 root root 620 Dec  5 17:37 ..

  [Inside the armhf chroot:]
  # ls -la /{dev,run}/sh*
  lrwxrwxrwx 1 root root  8 Oct 27 13:58 /dev/shm -> /run/shm

  /run/shm:
  total 4
  drwxrwxrwt 2 root root   40 Dec  5 19:16 .
  drwxr-xr-x 6 root root 4096 Oct 27 13:59 ..

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: debootstrap 1.0.59ubuntu0.2
  ProcVersionSignature: Ubuntu 3.13.0-40.69-generic 3.13.11.10
  Uname: Linux 3.13.0-40-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.5
  Architecture: amd64
  Date: Fri Dec  5 19:14:23 2014
  Ec2AMI: ami-00000052
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: production
  Ec2InstanceType: m1.jenkins.builder.prod
  Ec2Kernel: aki-00000002
  Ec2Ramdisk: ari-00000002
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: debootstrap
  UpgradeStatus: No upgrade log present (probably fresh install)

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