[lfs-dev] Issue with /dev/shm on host system.

John Joganic john at joganic.com
Thu Dec 20 11:49:55 PST 2012

I have put that in place, and it does appear to resolve the issue.

Is there a process in the LFS community to update the instructions? 
Given that, as written, the process can break the host, it seems
appropriate to at least include a warning.

Thank you for the quick reply.


> Pierre Labastie <mailto:pierre.labastie at neuf.fr>
> December 20, 2012 11:40 AM
> Why not create the $LFS/run dir at this stage and mount a tmpfs on it,
> then mkdir $LFS/run/shm and mount a tmpfs on it.
> Something like:
> if [ -h $LFS/dev/shm ]; then
> mkdir -p $/LFS/run/shm
> mount -vt tmpfs shm $LFS/run/shm
> fi
> Perhaps with a readlink to assess that the link is really /run/shm.
> Of course, there would be something similar when exiting chroot:
> if [ -h $LFS/dev/shm ]; then
> umount $LFS/run/shm
> fi
> Pierre
> John Joganic <mailto:john at joganic.com>
> December 20, 2012 11:10 AM
> In the stable LFS book, the host /dev directory is mounted into the
> chroot environment using a bind mount.
> mount -v --bind /dev $LFS/dev
> Next, the following command removed a symbol link and mounted tmpfs
> for the chroot environment, but there's nothing prescribed to fix up
> the host after /dev/shm is removed.
> if [ -h /dev/shm ]; then
> rm -f $LFS/dev/shm
> mkdir $LFS/dev/shm
> fi
> mount -vt tmpfs shm $LFS/dev/shm
> The result is that, for Ubuntu 12, the Chromium web browser crashed
> when it could no longer access shared memory. I remedied this by
> re-mounting tmpfs on /dev/shm, but I'm not certain that that will
> survive a reboot. As I'm not finding shm in /etc/fstab at all, it's
> not clear to me how it
> came to be mounted in the first place.
> Is there perhaps a cleaner way to populate the chroot /dev directory
> than bind mounting it to the host environment? If it was
> copy-on-write, I'd be less concerned, but as it stands, this method
> seems a little dangerous. Just my two cents.
> -John Joganic

More information about the lfs-dev mailing list