On machines with ancient kernels not including https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b87a267eb7291d075df76ebabd43c7f961b12f67 (like RHEL5), /proc/mounts does not include mount options for devpts, so when trying to set up a RAP prefix on these machines the test at the end of sys-libs/glibc/files/eblits/pkg_preinst.eblit fails: # Make sure devpts is mounted correctly for use w/out setuid pt_chown. if in_iuse suid && ! use suid ; then if awk '$3 == "devpts" && $4 ~ /[, ]gid=5[, ]/ { exit 1 }' /proc/mounts ; then eerror "In order to use glibc with USE=-suid, you must make sure that" eerror "you have devpts mounted at /dev/pts with the gid=5 option." eerror "Openrc should do this for you, so you should check /etc/fstab" eerror "and make sure you do not have any invalid settings there." die "mount & fix your /dev/pts settings" fi fi A possible solution is to check /etc/mtab in addition to /proc/mounts and only fail if the option is missing from both files. $ grep devpts /proc/mounts devpts /dev/pts devpts rw 0 0 $ grep devpts /etc/mtab devpts /dev/pts devpts rw,gid=5,mode=620 0 0 $ uname -r 2.6.18-308.11.1.el5PAE I suspect this would also affect non-prefix if someone was running a 5-year-old kernel on a normal Gentoo system.
Created attachment 362948 [details, diff] pkg_preinst patch After thinking about this for a while I'm worried that checking /etc/mtab might break chroot installs or some other corner case I'm not thinking of, so I propose instead just skipping the /proc/mounts test for kernels that are too old. The attached patch only contains the changes to the eblit. The ebuilds also need to be modified to inherit linux-info.
This is failing for me with openrc-0.12.X and 3.11.X. datastore4 ~ # grep devpts /proc/mounts devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0 datastore4 ~ # grep devpts /etc/mtab devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 datastore4 ~ # uname -a Linux datastore4 3.11.5-gentoo-datastore4 #1 SMP Wed Oct 16 12:29:53 EDT 2013 x8 6_64 Intel(R) Xeon(R) CPU E31230 @ 3.20GHz GenuineIntel GNU/Linux
For me the failure appears to be caused by lxc. http://forums.gentoo.org/viewtopic-t-977048-highlight-.html
I'm experiencing this on normal amd64 gentoo too. root@swanson.yac # grep pts /etc/mtab /dev/pts /dev/pts devpts rw,relatime,mode=600 0 0 root@swanson.yac # grep pts /etc/fstab /dev/pts /dev/pts devpts defaults 0 root@swanson.yac # uname -a Linux swanson.yac 3.6.11-gentoo #4 SMP Sat Aug 24 02:53:37 CEST 2013 x86_64 Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz GenuineIntel GNU/Linux
maybe in my case it is because this is ancient system and I shouldn't have pts in fstab anymore.
running:: umount -l /dev/pts; mount devpts -t devpts /dev/pts -o rw,nosuid,noexec,relatime,gid=5,mode=620 fixed it for me.
Comment on attachment 362948 [details, diff] pkg_preinst patch unfortunately, yes, we cannot rely on /etc/mtab being correct. if you do `mount -t devpts /foo`, you will break the mount options of /dev/dpts too (as all devpts instances are shared). or if someone does a remount with the -n flag.
(In reply to William Throwe from comment #0) that commit made it into 2.6.25. the # of people who are using <2.6.25 is probably low, so we could just make it into a warning if your kernel is that old and hope for the best.
I hit it again but now I at least know what may be causing messages:: root@swanson.yac # xsel -b xsel: Can't open display: (null) : Success It started right after the failed install of glibc. Would it be possible to add a check on the proper devpts, *before* the glibc is compiled so it fails fast?
Oh wait, I'm being an idiot, the xsel error is unrelated but the rest is still valid.
should be all set now in the tree; thanks for the report! Commit message: Do not die when the devpts check fails and we are on an old kernel http://sources.gentoo.org/sys-libs/glibc/files/eblits/pkg_preinst.eblit?r1=1.11&r2=1.12
