Bug 510183 - mock mounts /dev/pts in chroot with wrong options
Summary: mock mounts /dev/pts in chroot with wrong options
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 12
Hardware: All
OS: Linux
urgent
high
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 538923 538940 538947 538955 538960 539054
TreeView+ depends on / blocked
 
Reported: 2009-07-08 07:59 UTC by Jakub Jelinek
Modified: 2015-05-19 14:57 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-24 13:12:09 UTC


Attachments (Terms of Use)
mock-devpts.patch (669 bytes, patch)
2009-07-08 07:59 UTC, Jakub Jelinek
no flags Details | Diff
reworked pts mount patch (992 bytes, text/plain)
2009-07-08 19:36 UTC, Clark Williams
no flags Details

Description Jakub Jelinek 2009-07-08 07:59:09 UTC
Created attachment 350902 [details]
mock-devpts.patch

/dev/pts needs to be mounted with gid=5,mode=620.  Anaconda in Fedora 11 and probably all mock versions as well get it wrong though.  This means /dev/pts/* devices are created with wrong group (not tty) and mode 600 rather than POSIX required 620.  Older glibcs have been ignoring this, but 2.10.90 in rawhide requires it, otherwise grantpt fails (thus, e.g. all gcc make check tests fail).

I've briefly tested the patched mock on my F11 box and it fixed the problem.

Can this be fixed in mock and the fixed mock installed on koji build boxes?

Comment 1 Andreas Schwab 2009-07-08 14:55:33 UTC
Since there is only a single system-wide set of options for the devpts filesystem this breaks /dev/pts also in the host system.

Comment 2 Clark Williams 2009-07-08 16:40:36 UTC
Patch applied, will go out in next release (0.9.17)

Comment 3 Yanko Kaneti 2009-07-08 18:55:53 UTC
For systems with kernels 2.6.29 and later you should also probably use the newinstance devpts mount option to avoid any tampering with the host system.

Comment 4 Clark Williams 2009-07-08 19:36:05 UTC
Created attachment 350989 [details]
reworked pts mount patch

I reworked Jakub's original patch to not hardcode the 'tty' group and to add the 'newinstance' mount options if uname()[2] >= '2.6.29'. Think this will do it?

Comment 5 Clark Williams 2009-07-08 19:44:40 UTC
Well, it would probably do it except for the typo I introduced (+==). Fixed now.

Comment 6 Clark Williams 2009-07-08 21:01:48 UTC
Hmmm, looking in my 2.6.30 tree, devpts doesn't seem to have a newinstance option. Yanko, are you sure about that option and kernel version?

Comment 7 Clark Williams 2009-07-08 21:10:32 UTC
well, it would help if:

1. I were in the right branch of my git tree (I was in a 2.6.24 branch)

and 

2. I had my kernel compiled wiht the newinstance config option

never mind...

Comment 8 Yanko Kaneti 2009-07-08 21:41:49 UTC
Ok then :) (clearing that needinfo flag) . I just tried it with rawhide userspace and f11 kernel and it works.
Speaking of rawhide , it would be nice to get a fixed mock sooner, because this issue has some unpleasant consequences -> bug 509632

Comment 9 Clark Williams 2009-07-08 22:05:35 UTC
Yeah, I'm working through our testing now. Figure to get a brew build out tonight and then see if we can get Jesse to up date the build boxes tomorrow.

Comment 10 Paul Howarth 2009-09-10 11:15:51 UTC
The newinstance option has caused me a problem with mock on F-11 when trying to build perl-Expect (mock-0.9.17-3.fc11, kernel-2.6.29.6-217.2.16.fc11.x86_64). The test suite fails like this:

Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.XfvLUP
+ umask 022
+ cd /builddir/build/BUILD
+ cd Expect-1.21
+ unset DISPLAY
+ /usr/bin/make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
IO::Tty::pty_allocate(nonfatal): grantpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): ptsname_r(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): open(/dev/pts/8): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): posix_openpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::pty_allocate(nonfatal): grantpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): open(/dev/pts/8): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): getpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): openpty(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::pty_allocate(nonfatal): grantpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): open(/dev/pts/8): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): open(/dev/ptmx): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
Cannot open a pty at test.pl line 34
1..42
Basic tests...
make: *** [test_dynamic] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.XfvLUP (%check)

This fail happens for both F-11 and devel targets.

If I comment out the two lines:

        if os.uname()[2] >= '2.6.29':
            mountopt += ',newinstance'

in /usr/lib/python2.6/site-packages/mock/backend.py, the test suite passes as before.

Perhaps some fiddling with /dev/ptmx is also needed, as mentioned in http://www.mjmwired.net/kernel/Documentation/filesystems/devpts.txt?

Comment 11 Jesse Keating 2009-10-21 22:38:22 UTC
Seems we missed the boat for this on F12, it's too late to change out mock right now.  Punting to after F12.

Comment 12 Bug Zapper 2009-11-16 10:43:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Matt Domsch 2009-11-20 21:16:20 UTC
Still seeing several reports of failure even with mock-0.9.19-1.fc12.noarch which is in Fedora 12.  See all the above blocked bugs.  Failures aren't happening on the buildsystems because their glibc is older.

The builders have:
$ uname -r
2.6.18-164.2.1.el5
$ rpm -q glibc
glibc-2.5-42.x86_64
glibc-2.5-42.i686
$ rpm -q mock
mock-0.9.14-2.el5.noarch

Clark, can you investigate and push out a fix?

Comment 14 Clark Williams 2009-11-20 22:35:48 UTC
I pulled the perl-Expect SRPM as a test platform and tried building it on my F11 laptop with:

$ mock -r fedora-11-x86_64 perl-Expect-1.21-2.fc11.src.rpm

This failed with the errors listed in other bugs (i.e. failed to create a pty). Logging into the chroot using 'mock --shell -r fedora-11-x86_64'  I noticed that while /proc/mounts reports that we have /dev/pts mounted, it does not contain the special file ptmx (which should be created as a consequence of mounting devpts). Mounting a new instance of devpts while in the chroot to /dev/foo does in fact create the ptmx file. 

Investigating further...

Comment 15 Fedora Update System 2009-11-23 16:23:27 UTC
mock-1.0.0-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.fc12

Comment 16 Fedora Update System 2009-11-23 16:24:25 UTC
mock-1.0.0-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.fc11

Comment 17 Fedora Update System 2009-11-23 16:25:23 UTC
mock-1.0.0-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.fc10

Comment 18 Fedora Update System 2009-11-23 16:47:56 UTC
mock-1.0.0-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.el5

Comment 19 Fedora Update System 2009-11-23 16:48:35 UTC
mock-1.0.0-1.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.el4

Comment 20 Matt Domsch 2009-11-24 13:12:09 UTC
 mock-1.0.0-1.fc12 fixes the /dev/pty* problems.  Closing.

Comment 21 Paul Howarth 2010-02-09 12:03:48 UTC
(In reply to comment #14)
> I pulled the perl-Expect SRPM as a test platform and tried building it on my
> F11 laptop with:
> 
> $ mock -r fedora-11-x86_64 perl-Expect-1.21-2.fc11.src.rpm
> 
> This failed with the errors listed in other bugs (i.e. failed to create a pty).
> Logging into the chroot using 'mock --shell -r fedora-11-x86_64'  I noticed
> that while /proc/mounts reports that we have /dev/pts mounted, it does not
> contain the special file ptmx (which should be created as a consequence of
> mounting devpts). Mounting a new instance of devpts while in the chroot to
> /dev/foo does in fact create the ptmx file. 
> 
> Investigating further...    

Just spotted another curiosity, which may or may not be related to this. I tried building a perl-TermReadKey package on my F-12 (x86_64) builder (devel.x86_64 target, though the target doesn't seem to matter), and the test suite, which does a bunch of stuff with /dev/tty, appears to hang. Running locally outside mock, there's no problem. If I do a koji srpm-scratch-build of the same package, it skips the test suite because it can't open /dev/tty for reading (see http://koji.fedoraproject.org/koji/getfile?taskID=1971239&name=build.log). I guess this is due to the underlying host being different?

I wonder if this is a problem that is lying in wait for us if/when the buildsystem moves on to RHEL6?

Can anybody reproduce this issue?

Comment 22 Ralf Corsepius 2010-07-02 15:49:37 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=609201
seems to be another incarnation rsp. a similar incarnation of this bug.

Comment 23 Daniel Riek 2011-06-13 03:05:07 UTC
I am trying to compile python-2.7.1 on RHEL 6 with a Fedora 15 target (just to get a baseline) and I get the below - so I guess there still is something broken there...

test_pty
test test_pty failed -- Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.1/Lib/test/test_pty.py", line 114, in t
est_fork
    pid, master_fd = pty.fork()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 107, in fork
    master_fd, slave_fd = openpty()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 29, in openpty
    master_fd, slave_name = _open_terminal()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 70, in _open_termin
al
    raise os.error, 'out of pty devices'
OSError: out of pty devices
Re-running test 'test_pty' in verbose mode
test_basic (test.test_pty.PtyTest) ... skipped 'Pseudo-terminals (seemingly) not
 functional.'
test_fork (test.test_pty.PtyTest) ... ERROR
======================================================================
ERROR: test_fork (test.test_pty.PtyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.1/Lib/test/test_pty.py", line 114, in t
est_fork
    pid, master_fd = pty.fork()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 107, in fork
    master_fd, slave_fd = openpty()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 29, in openpty
    master_fd, slave_name = _open_terminal()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 70, in _open_terminal
    raise os.error, 'out of pty devices'
OSError: out of pty devices
----------------------------------------------------------------------
Ran 2 tests in 0.006s
FAILED (errors=1, skipped=1)
test test_pty failed -- Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.1/Lib/test/test_pty.py", line 114, in test_fork

Comment 24 David Caro 2015-05-19 14:50:32 UTC
I'm abusing mock a bit to allow me to run some scripts inside a chroot easily, and I found that if I use pexpect inside the chroot (any distro) it fails with a very similar error:


     File "/tmp/run/.tox/functional/lib/python2.7/site-packages/pexpect/__init__.py", line 511, in __init__
       self._spawn(command, args)
     File "/tmp/run/.tox/functional/lib/python2.7/site-packages/pexpect/__init__.py", line 630, in _spawn
       raise ExceptionPexpect('pty.fork() failed: ' + str(err))
   pexpect.ExceptionPexpect: pty.fork() failed: out of pty devices


Is there a workaround to this?

Comment 25 David Caro 2015-05-19 14:57:17 UTC
It actually seems to happen only if I specifically mount the /dev on the mock options, if letting mock populate it it works well... but I need some of the devices there...


Note You need to log in before you can comment on or make changes to this bug.