Bug 510183 - mock mounts /dev/pts in chroot with wrong options
mock mounts /dev/pts in chroot with wrong options
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
12
All Linux
urgent Severity high
: ---
: ---
Assigned To: Clark Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 538923 538940 538947 538955 538960 539054
  Show dependency treegraph
 
Reported: 2009-07-08 03:59 EDT by Jakub Jelinek
Modified: 2015-05-19 10:57 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-24 08:12:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Jakub Jelinek 2009-07-08 03:59:09 EDT
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 10:55:33 EDT
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 12:40:36 EDT
Patch applied, will go out in next release (0.9.17)
Comment 3 Yanko Kaneti 2009-07-08 14:55:53 EDT
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 15:36:05 EDT
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 15:44:40 EDT
Well, it would probably do it except for the typo I introduced (+==). Fixed now.
Comment 6 Clark Williams 2009-07-08 17:01:48 EDT
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 17:10:32 EDT
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 17:41:49 EDT
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 18:05:35 EDT
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 07:15:51 EDT
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 18:38:22 EDT
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 05:43:39 EST
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 16:16:20 EST
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 17:35:48 EST
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 11:23:27 EST
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 11:24:25 EST
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 11:25:23 EST
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 11:47:56 EST
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 11:48:35 EST
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 08:12:09 EST
 mock-1.0.0-1.fc12 fixes the /dev/pty* problems.  Closing.
Comment 21 Paul Howarth 2010-02-09 07:03:48 EST
(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 11:49:37 EDT
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-12 23:05:07 EDT
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 10:50:32 EDT
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 10:57:17 EDT
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.