Opened 12 years ago
Closed 12 years ago
#3258 closed defect (fixed)
Mounting /dev/shm can break some hosts
Reported by: | Matthew Burgess | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.3 |
Component: | Book | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
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.
Change History (6)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Description: | modified (diff) |
---|
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.
comment:3 by , 12 years ago
Hi Bruce,
That change looks good to me. Well spotted. I can make the equivalent change in jhalfs (LFS/master.sh), unless you want to handle that too?
Thanks,
Matt.
comment:4 by , 12 years ago
I'll go ahead and fix the book, but I'll let you fix jhalfs. I've just been umounting manually right now for testing.
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
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.