the problem is that in my final system /dev/shm/ has not been correctly set as permission 777, thus non privileged user fail to use posix semaphore, calling sema_open(), sema_close() will result in "permission denied", since it has no permission to create file in /dev/shm/. machine has problem: # ls /dev/ -l |grep shm drwxr-xr-x 2 root root 60 Dec 4 19:34 shm root cause it that initramfs mount /dev/shm early and with wrong permission, thus udev-mount won't do later.. offend code as following which should be removed, to fix this problem. ./genkernel-next-47/defaults/linuxrc:19:mount -t tmpfs none /dev/shm 2>&1 Reproducible: Always
To fill in a few gaps here: We had a conversation in #gentoo-dev-help in which we discovered that /dev/shm was being mounted before /dev on dlan's system: none /dev/shm tmpfs rw,relatime,size=5974036k,nr_inodes=1493509 0 0 udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=1491053,mode=755 0 0 When /dev is mounted after /dev/shm, it masks/hides the latter.
Setting severity to major since this will cause dev-lang/python to be built without semaphore support, which breaks several packages.
This is on my system, using systemd and kernel+initramfs built with genkernel-next. What is your init system? I guess that you're using openrc? fabio@lxnaylap ~ $ stat /dev/shm File: "/dev/shm" Dim.: 260 Blocchi: 0 Blocco di IO: 4096 directory Device: 11h/17d Inode: 4795 Coll.: 2 Accesso: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) Accesso : 2013-12-08 17:36:35.063251849 +0100 Modifica : 2013-12-08 17:36:19.917206361 +0100 Cambio : 2013-12-08 17:36:19.917206361 +0100 Creazione: -
And most importantly, are you using mdev or udev on the initramfs?
*genkernel-next-49 (08 Dec 2013) 08 Dec 2013; Fabio Erculiani <lxnay@gentoo.org> -genkernel-next-40.ebuild, -genkernel-next-47.ebuild, +genkernel-next-49.ebuild: version bump, also fix bug #493346
A couple of problems here: 1. /dev is still being mounted after /dev/shm, which means that the /dev/shm mount point is masked. 2. busybox's mount does not seem to support the strictatime option. I'll work on a better patch.
I should have fixed it all here: https://github.com/Sabayon/genkernel-next/commit/8ae92b7601003e7ee6ad35e954df797363d8b66c It should work, but it needs a bit of testing. Sorry for the inconvenience.
Looks good to me; I did a quick test with openrc in qemu, and it looks more normal.
(In reply to Fabio Erculiani from comment #7) > It should work, but it needs a bit of testing. > Sorry for the inconvenience. tested, works fine here (eudev-1.3 + openrc), thanks @lxnay and @floppym
(In reply to Fabio Erculiani from comment #7) > I should have fixed it all here: > https://github.com/Sabayon/genkernel-next/commit/ > 8ae92b7601003e7ee6ad35e954df797363d8b66c > > It should work, but it needs a bit of testing. > Sorry for the inconvenience. It worked with genkernel-next-50 but _only_ after recreating the initramfs using: CLEAR_CACHE_DIR="yes" genkernel initramfs (CLEAR_CACHE_DIR is by default commented in /etc/genkernel.conf) Is there an automatical way for genkernel-next to force recompilation of a component (in this case busybox) after adding a patch?
It worked with genkernel-next-50 but _only_ after recreating the initramfs using: CLEAR_CACHE_DIR="yes" genkernel initramfs (CLEAR_CACHE_DIR is by default commented in /etc/genkernel.conf) Sorry forgot to mention that without busybox recompilation I saw something like this during load of the initramfs /dev/shm not mounted because of unknown parameters
*** Bug 498042 has been marked as a duplicate of this bug. ***
bug fixed, so close it. to @Walter Meinl, you should open another bug for your problem, keep one thread per bug, or check bug 498042 to if it's actually same problem.
