Created attachment 426042 [details] build.log The chromium build fails to build with a permission denied error. I'm building this in a chroot and it is running as root. It's never happened before so not sure why it is happening now. Build log attached.
Created attachment 426044 [details] emerge --info
Could be that the build requires write access to /dev/shm http://stackoverflow.com/questions/2009278/python-multiprocessing-permission-denied
Right. /dev/shm should be mounted as a tmpfs with mode 1777 in your chroot environment. For optimal portage behavior, you should also have /dev and /dev/pts mounted properly so that pty allocation will work. Recursively bind-mounting /dev onto CHROOT/dev also works.
Great. That was the issue. Now that build compiled fine in my chroot. Mike, I used to use rbind and that's why it didn't happen before. However, I had another problem with my actual system because if I used --rbind and then I did an umount, it actually screwed up the mount points on the main system, and then my server would actually hang when I did a reboot/shut down (It would hang at the shutdown step.. probably because some mount point that was recursively mounted was mest up during my exiting of the chroot). What I do now and what solved the problem is to do normal mounts (since the normal mounts can be unmounted without actually messing up the main mount). The following works: mount --bind /proc "${_ChrootDir}"/proc mount --bind /dev "${_ChrootDir}"/dev mount --bind /dev/pts "${_ChrootDir}"/dev/pts mount --bind /dev/shm "${_ChrootDir}"/dev/shm mount --bind /sys "${_ChrootDir}"/sys and then when we exit chroot: umount "${_ChrootDir}"/{proc,dev/pts,dev/shm,dev,sys} all this is automated of course. Closing this ticket.
(In reply to Jonathan Vasquez from comment #4) > Great. That was the issue. Now that build compiled fine in my chroot. > > Mike, I used to use rbind and that's why it didn't happen before. However, I > had another problem with my actual system because if I used --rbind and then > I did an umount, it actually screwed up the mount points on the main system, > and then my server would actually hang when I did a reboot/shut down (It > would hang at the shutdown step.. probably because some mount point that was > recursively mounted was mest up during my exiting of the chroot). That behavior is a well-known issue with shared subtrees, which systemd enables by default. A workaround for that: mount --make-rslave "${_ChrootDir}" That converts them from "shared" mounts to "slave" mounts, which means that umount-ing them works more normally.
Ah. Thanks for the info, I was also getting this with OpenRC as well, so it's nice to know systemd at least is taking this into consideration.
