Re: [lmi] Missing system directories in chroot [Was: Creating a chroot for cross-building lmi]

[Greg Chicares]

On 2016-09-16 12:50, Greg Chicares wrote:
[...]
> $google-chrome-stable
> [23923:23942:0916/115326:ERROR:bus.cc(434)] Failed to connect to the bus: 
> Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or 
> directory
> [23923:23923:0916/115326:ERROR:shared_memory_posix.cc(290)] Creating shared 
> memory in /dev/shm/.com.google.Chrome.YTpEOQ failed: No such file or directory
> [23923:23923:0916/115326:ERROR:shared_memory_posix.cc(293)] Unable to 
> access(W_OK|X_OK) /dev/shm: No such file or directory
> [23923:23923:0916/115326:FATAL:shared_memory_posix.cc(295)] This is 
> frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 
> /dev/shm' to fix.
> zsh: abort      google-chrome-stable
> 
> Yesterday, without schroot "type=directory", I encountered this problem
> and solved it by following that "sudo chmod 1777 /dev/shm" advice. But
> today I hesitate to do that, because I suspect /dev/shm is just a link
> to the underlying OS's own directory (which I'm reluctant to change
> without deeper knowledge than I possess), and also because it seems to
> have the right permissions:
[...]
> $ls -l /dev/sh*
> lrwxrwxrwx 1 root root 8 Feb 16  2016 /dev/shm -> /run/shm

That might be a dangling symlink, because:
  $ls /run/sh*
  zsh: no matches found: /run/sh*

I found this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096
| Is it possible that schroot is actually trying to resolve the /dev/shm
| -> /run/shm symlink outside of the chroot?
...
| Simply removing the /dev/shm link inside the chroot and making it a
| directory should make things work.
...
| Users have hit this issue in Ubuntu, too. I've triaged it and have
| determined that Laurent is correct in Message #17 that the schroot mount
| helper is using the host's filesystem to resolve symlinks in the chroot.

Ignoring my own good advice above, I tried the suggested workaround:
  sudo rm /dev/shm
Before doing that in the chroot, I did this outside the chroot:
  $ls -l /dev/sh*
  lrwxrwxrwx 1 root root 8 Feb 16  2016 /dev/shm -> /run/shm
After running 'rm' in the chroot, I found this, outside the chroot:
  $ls -l /dev/sh*
  zsh: no matches found: /dev/sh*
so I quickly put it back, in the host system:
  $sudo ln -s /run/shm /dev/shm
  $ls -l /dev/sh*
  lrwxrwxrwx 1 root root 8 Sep 16 13:50 /dev/shm -> /run/shm
I hope that didn't do any damage.

I created a /dev/shm directory (not a link) inside the chroot:
  $ls -l /srv/chroot/chrome/dev/ |grep shm
  drwxrwxrwt 2 root root  4096 Sep 16 02:11 shm
hoping that this would cause the 'ln' at startup to fail, but if I
leave and reenter the chroot, I get:
  ls -l /dev/shm
  lrwxrwxrwx 1 root root 8 Sep 16 13:50 /dev/shm -> /run/shm
and google-chrome-stable refuses to run, with the same diagnostics
as before:
  Unable to access(W_OK|X_OK) /dev/shm: No such file or directory

Let's try creating something on the other end of the link:
  $sudo mkdir /srv/chroot/chrome/run/shm
  $sudo chmod 1777 /srv/chroot/chrome/run/shm
Now I can run google-chrome-stable. And yesterday's sound-card
problems are no longer observed: Monk's playing "Don't Blame Me"
now, and I can hear the dampers buzzing because the microphone
is misplaced. So my current working hypothesis is that schroot
should be used with "directory" type, with /run/shm forcibly
created to work around the defect mentioned above--I like that
better than the workaround mentioned here:
  https://lists.gnu.org/archive/html/guix-devel/2014-01/msg00144.html
| remove the symlink from the host system, create /dev/shm directory
| and mount a tmpfs on it.

Next step is to try installing lmi into such a chroot. Then maybe
next week we can do the same thing on redhat, which probably has
its own distinct set of defects.

I just hope I didn't break anything by temporarily unlinking
/dev/shm on the host.