Mounting /dev/shm can break some hosts

[Matthew Burgess]

As reported at ​http://www.linuxfromscratch.org/pipermail/lfs-dev/2012-December/067476.html the instructions to work around the fact that some hosts have symlinked /dev/shm to /run/shm can in fact break those hosts. Once the /dev/shm symlink is removed from the host, it's never recreated!

The fix from Pierre, in that thread, looks good:

if [ -h $LFS/dev/shm ]; then
   mkdir -p $LFS/run/shm
   mount -vt tmpfs shm $LFS/run/shm
fi

So, we mount the shm FS into the target of the symlink, rather than removing the symlink.

We'll need to add an errata item for this as well.

[bdubbs@…]

I'm not sure about the change. I agree that removing /dev/shm from the host is a problem, but does $(mkdir -p $/LFS/run/shm) within the chroot environment affect the host? I suspect it normally does nothing as the item that the symlink points to is a directory so the -p in mkdir just exits, doing nothing.

There could also be an issue of lack of isolation in the proposed change in that nothing is done if the symlink does exist. Would just the line:

mount -vt tmpfs shm $LFS/run/shm

mount a new tmpfs over the old for use within chroot be better?

AFAIR the only reason for /dev/shm to exist in chroot is to satisfy some tests in glibc.

[bdubbs@…]

I've been thinking about this some more and the proposed solution appears to be correct for the case when the /dev/shm -> /run/shm symlink is present.

I'm not sure about the case when the symlink is not present, wouldn't we want to mount a new tmpfs directly on $LFS/dev/shm like we do now? Also, we probably don't want to make assumptions for where the symlink is pointing.

if [ -h $LFS/dev/shm ]; then
   link=$(readlink $LFS/dev/shm)
   mkdir -p $LFS/$link
   mount -vt tmpfs shm $LFS/$link
   unset link
else
   mount -vt tmpfs shm $LFS/shm 
fi

I'll make the change if we agree that this is the right way to go.