From Bug 496328, floppym seems to indicate the handbook is completely broken as /dev/shm isn't mounted as part of the chroot instructions. I hit the trap, apparently others are as well. It would be nice to have a line for mounting /dev/shm, and have it working in the chroot as there are (now) malicious ebuilds that check for it.
For the record, I never said the handbook is completely broken, nor anything to that effect.
Just to make this bug a little more useful: It was proposed that perhaps we should change the following command in the handbook: mount --rbind /dev /mnt/gentoo/dev Into 3 commands: mount --bind /dev /mnt/gentoo/dev mount --bind /dev/pts /mnt/gentoo/dev/pts mount -t tmpfs shm /mnt/gentoo/dev/shm The last of these 3 commands would create a new tmpfs for shared memory within the chroot environment, which could prevent conflicts between processes inside and outside the chroot. Personally, I have never witnessed such a conflict, but it could happen in theory.
(In reply to Mike Gilbert from comment #1) > For the record, I never said the handbook is completely broken, nor anything > to that effect. (In reply to Mike Gilbert from Bug 496328 comment #1) > Honestly, I don't feel it is our responsibility to tell you how to properly > configure a chroot build environment. Our installation handbook already > properly documents that. So my initial reaction is to reject this request. > > However, I can see the value in preventing broken systems. (In reply to Mike Gilbert from Bug 496328 comment #18) > This bug is finding quite a few configurations that were simply broken, and > nobody noticed. I would prefer to leave it as-is. I could be looking too deep into this, which is usually the case. Thanks for fixing the documentation in the bug though; I'm really horrible with phrasing (as you've likely already noted ;-) ).
(In reply to Kyle Sanderson from comment #3) I think we are talking past one another. I have been saying that the handbook is fine all along. There are a couple of things we have found to be broken: 1. catalyst was broken, and is now fixed. 2. SELinux policy was broken, and a fix is in progress. There is some unknown problem with YOUR system/install environment that causes the instructions in the handbook to not work for YOU. We have not figured out exactly what that is.
I also have /dev/mqueue as a separate mount. Should it be mounted explicitly as well?
I am not familiar enough with that to answer that.
(In reply to Mike Gilbert from comment #4) > (In reply to Kyle Sanderson from comment #3) > > I think we are talking past one another. I have been saying that the > handbook is fine all along. > > There are a couple of things we have found to be broken: > > 1. catalyst was broken, and is now fixed. > 2. SELinux policy was broken, and a fix is in progress. > > There is some unknown problem with YOUR system/install environment that > causes the instructions in the handbook to not work for YOU. We have not > figured out exactly what that is. For what it's worth, I (In reply to Mike Gilbert from comment #4) > (In reply to Kyle Sanderson from comment #3) > > I think we are talking past one another. I have been saying that the > handbook is fine all along. > > There are a couple of things we have found to be broken: > > 1. catalyst was broken, and is now fixed. > 2. SELinux policy was broken, and a fix is in progress. > > There is some unknown problem with YOUR system/install environment that > causes the instructions in the handbook to not work for YOU. We have not > figured out exactly what that is. For what it's worth, I hit the same bug when doing the mount --rbind stuff as well. I believe it's related to the fact that outside the chroot, at least on this ubuntu live DVD I'm using, /dev/shm is a symlink to /run/shm and when we --rbind it, inside the chroot it's a symlink to nothing. And just doing "mount --bind /dev/ /mnt/gentoo/dev" and later doing "mount -t tmpfs shm /dev/shm" didn't do any good, as it simply made a second symlinked mountpoint. The only way I was able to do it was to --bind /dev and /dev/pts then go into the chroot, remove /dev/shm, create it as a directory with 1777, then do "mount -t tmpfs shm /dev/shm" Only after that was I able to get python to install properly.
(In reply to Chris Slycord from comment #7) Ah, thanks for that insight. I think the handbook still assumes you are using a Gentoo installcd though.
Yes; we have to assume that anyone using a different installation CD can deal with the changes in the environment. It is quite hard to follow through on the differences between other media. What are they thinking, making /dev/shm -> /run/shm... that only to save a tmpfs mount?
*** Bug 509808 has been marked as a duplicate of this bug. ***
Applied the following: diff -u -B -r1.145 hb-install-system.xml --- hb-install-system.xml 13 Apr 2014 11:58:00 -0000 1.145 +++ hb-install-system.xml 1 Jun 2014 13:36:05 -0000 @@ -109,6 +109,21 @@ # <i>mount --rbind /dev /mnt/gentoo/dev</i> </pre> +<!-- +Only warning for non-Gentoo installation media. The more other installation +media diverge from ours, the more difficult it will be to create proper +documentation. If this becomes a larger issue, we will need to include a +single warning up front, and perhaps have a wiki page where users can put the +differences, so that the installation instructions can focus on Gentoo-only +media. +--> +<warn> +When using non-Gentoo installation media, this might not be sufficient. +Some distributions make <path>/dev/shm</path> a symbolic link to +<path>/run/shm</path> which, after the chroot, becomes invalid. Making +<path>/dev/shm</path> a proper tmpfs-mount up front can fix this. +</warn> + </body> </subsection> <subsection>
