Mount indicates that /dev is devtmpfs and /run is tmpfs, so you are correct; they must be getting regenerated on boot.
Thank you, -John > Matt Burgess <mailto:matt...@linuxfromscratch.org> > December 20, 2012 1:25 PM > > I've just created a ticket in our Trac system > (http://wiki.linuxfromscratch.org/lfs/ticket/3258) to make sure this > isn't forgotten about. > > Thanks for the report, and thanks to Pierre for the quick fix. > > John, I think that /run should be a tmpfs on your Ubuntu host, but could > you confirm please? If it is, then your /run/shm directory will be > recreated on a reboot. > > Could you also confirm that /dev is also a tmpfs (or devtmpfs) please? > That should mean that the /dev/shm symlink will also be recreated on a > reboot (I'm assuming here that there's a udev rule or > a /lib/udev/devices/shm node around that will achieve this. Therefore I > don't think any permanent damage will have been done to your host. > > Regards, > > Matt. > > John Joganic <mailto:j...@joganic.com> > December 20, 2012 12:49 PM > 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. > > -John > > Pierre Labastie <mailto:pierre.labas...@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:j...@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 > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
