Bug 683111 - /dev/tty and /dev/ptmx are not created in epel-5 based chroots on F14
Summary: /dev/tty and /dev/ptmx are not created in epel-5 based chroots on F14
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 14
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 701891 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-08 15:36 UTC by Chris Gagne
Modified: 2013-01-10 06:30 UTC (History)
6 users (show)

Fixed In Version: mock-1.1.10-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-17 20:09:17 UTC
Type: ---


Attachments (Terms of Use)
proposed patch to create /dev/ptmx and /dev/tty when --shell is specified (1.89 KB, patch)
2011-03-10 17:33 UTC, Clark Williams
no flags Details | Diff
Patch to create tty and ptmx symlinks on Fedora and EL6 hosts (3.00 KB, patch)
2011-03-10 19:56 UTC, Chris Gagne
no flags Details | Diff
patch to setup /dev/ptmx and /dev/tty as symlinks on modern kernels with --shell (2.75 KB, patch)
2011-03-10 22:22 UTC, Clark Williams
no flags Details | Diff

Description Chris Gagne 2011-03-08 15:36:19 UTC
Description of problem:

We use the mock shell feature on Fedora 14 for development and testing of packages built for a RHEL5 platform. One of our tools launches an xterm inside a mock chroot. xterm expects /dev/tty and /dev/ptmx to exist.

Are there any plans to reintroduce creation of /dev/tty and /dev/ptmx on F14 hosts and greater? Code in mock/backend.py (lines 424 - 430) responsible for creating various symlinks in /dev appears to have been commented out in BZ# 609201. When uncommented, xterm works again.

Version-Release number of selected component (if applicable): 1.1.9-1


How reproducible: Always


Steps to Reproduce:
1. Initialize a chroot (eg. epel-5-x86_64)
2. Shell into the chroot using mock shell
3. ls -l /dev/tty
4. ls -l /dev/ptmx
  
Actual results:
The device files /dev/tty and /dev/ptmx were not created.

Expected results:
The device files /dev/tty and /dev/ptmx were created.

Additional info:

Comment 1 Clark Williams 2011-03-09 22:42:34 UTC
Chris,

I'm looking at adding them back when --shell is the active command. Will that do what you need?

Comment 2 Chris Gagne 2011-03-10 13:41:33 UTC
Hi Clark,

Would that work when --chroot is used as well?  If so I think that would cover our use cases.

Thanks,
Chris

Comment 3 Clark Williams 2011-03-10 15:13:18 UTC
Hmmmmmm.  Not as I currently have it coded. Let me play with it a bit. I suspect that if we add it with --chroot, we may start running into the same issues that we hit with packages test suites. But maybe that's just something we live with. 

If I post a patch can you test it?

Comment 4 Chris Gagne 2011-03-10 15:24:16 UTC
Yes. I'll test whatever you have.

Comment 5 Clark Williams 2011-03-10 16:58:18 UTC
Chris, 

I've looked at this and just can't see a good way to turn on creating those devs for --chroot without getting back into the situation we had previously where bash and other packages were failing to build.

I would suggest that you look at the bind_mount plugin in conjunction with the config option internal_dev_setup. Normally internal_dev_setup is True, but you could set it to false and use the bind_mount plugin to mount your own custom /dev inside the chroot. That way you can create the devices you want and not be dependent on our general-purpose solution. 

To do that you would set in /etc/mock/site-defaults.cfg:

     config_opts['internal_dev_setup'] = False

Then create a directory somewhere that has the special devices you want, let's say in /opt/mydevs, then do this:

     config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/opt/mydevs', '/dev' ))

Every time you run mock, it will bind_mount your directory to /dev in the chroot.

Comment 6 Chris Gagne 2011-03-10 17:18:28 UTC
Clark,

We're already bind mounting a few directories, so that shouldn't be too much work to get going. That said, is it still possible to have --shell create the devs? I had a second look at our tools and --shell covers the most important cases. --chroot would be nice to have, but not essential so I can work without it.

Comment 7 Clark Williams 2011-03-10 17:33:14 UTC
Created attachment 483521 [details]
proposed patch to create /dev/ptmx and /dev/tty when --shell is specified

Chris, 

I've attached a patch that will create /dev/ptmx and /dev/tty when --shell is specified. Please see if this does what you need.

Comment 8 Chris Gagne 2011-03-10 19:56:26 UTC
Created attachment 483552 [details]
Patch to create tty and ptmx symlinks on Fedora and EL6 hosts

Comment 9 Chris Gagne 2011-03-10 19:57:29 UTC
Clark,

Thanks. Although the device files /dev/ptmx and /dev/tty now exist, I get the following:

xterm: Error 32, errno 2: No such file or directory
Reason: get_pty: not enough ptys

strace shows:
stat("/dev/pts/9", 0x7fff780ba8b0)      = -1 ENOENT (No such file or directory)

I don't know enough about how the tty devs work, however what I do know is that mock 1.1.8 symbolic links /dev/ptmx to /dev/pts/ptmx and then /dev/tty to /dev/ptmx, which seems to work fine. It continues to work if I create those symbolic links manually when using mock 1.1.9.

Can the 'symlinks for Fedora and el6 hosts' be uncommented with an 'and interactive' added to the if statement? (see my patch above)

Comment 10 Clark Williams 2011-03-10 22:22:16 UTC
Created attachment 483585 [details]
patch to setup /dev/ptmx and /dev/tty as symlinks on modern kernels with --shell

Chris, 

Try this patch with the previous one for --shell and let me know if it does what you want.

Comment 11 Chris Gagne 2011-03-11 14:20:03 UTC
Clark, that works. Thank you.

Comment 12 Fedora Admin XMLRPC Client 2011-03-11 18:10:31 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 13 Clark Williams 2011-05-06 20:14:16 UTC
I've gone back to unconditionally creating the device nodes, so the next version of mock (1.1.10 / 1.0.17) should work for you.

Comment 14 Fedora Update System 2011-05-13 20:31:33 UTC
mock-1.1.10-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc15

Comment 15 Fedora Update System 2011-05-13 20:36:40 UTC
mock-1.1.10-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc14

Comment 16 Fedora Update System 2011-05-13 20:40:56 UTC
mock-1.0.17-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.17-1.el5

Comment 17 Fedora Update System 2011-05-13 20:45:06 UTC
mock-1.1.10-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.fc13

Comment 18 Fedora Update System 2011-05-13 20:49:22 UTC
mock-1.1.10-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.10-1.el6

Comment 19 Fedora Update System 2011-05-14 00:01:34 UTC
Package mock-1.1.10-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mock-1.1.10-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/mock-1.1.10-1.el6
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2011-05-19 04:33:05 UTC
mock-1.1.10-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2011-05-25 02:40:22 UTC
mock-1.1.10-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2011-05-25 03:14:55 UTC
mock-1.1.10-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2011-06-02 19:04:34 UTC
mock-1.0.17-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Fedora Update System 2011-06-02 19:14:37 UTC
mock-1.1.10-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 25 Jakub Jelinek 2011-06-28 09:38:25 UTC
This broke completely mock /dev/pt* handling on >= 2.6.29 kernels, all tests e.g. in gcc %check fail.  gcc built in koji just fine with dejagnu working on June 3rd, but the build from last few days fails.
Strace says:
17650 open("/dev/ptmx", O_RDWR)         = 9
17650 statfs("/dev/pts", {f_type="DEVPTS_SUPER_MAGIC", f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
17650 ioctl(9, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0x8a3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"}) = 0
17650 ioctl(9, TIOCGPTN, [16])          = 0
17650 stat64("/dev/pts/16", 0xffcab318) = -1 ENOENT (No such file or directory)
17650 fcntl64(9, F_GETFD)               = 0
This is on recent kernel, so devpts is apparently mounted with ,newinstance.
mount(8) manual page for devpts with newinstance option says:
"To use this option effectively, /dev/ptmx must be a symbolic link to  pts/ptmx."
so this breakage is easily explainable.
Can you please fix this ASAP, so that if ,newinstance is passed, /dev/ptmx is not a device, but pts/ptmx symbolic link?

Comment 26 Chris Gagne 2011-06-28 12:46:14 UTC
With mock 1.1.10 on a 2.6.35 kernel (F14 host, RHEL5 chroot) I'm still seeing this too.

Comment 27 Clark Williams 2011-06-28 17:49:26 UTC
Are you guys seeing it with the 1.1.11 where I dropped newinstance?

I'm reading the Documentation/filesystems/devpts.txt file now to see how we can correctly use newstance in a mock chroot. Hopefully I'll have this straightened out in 1.1.12.

Comment 28 Jakub Jelinek 2011-06-29 08:02:46 UTC
Yes, 1.1.11 works too, though I think it is unnecessary to remove newinstance if for the case where newinstance is used ptmx is always a symlink as required by the kernel.  Anyway, we need 1.1.11 or 1.1.12 into the koji builders ASAP.

Comment 29 Jakub Jelinek 2011-06-29 09:35:24 UTC
BTW, the ,ptmxmode=0666 addition should probably be added together with
,newinstance only on >= 2.6.29 kernels, if /dev/ptmx is a symlink only for those kernels, the mode of /dev/pts/ptmx doesn't matter on older kernels and those might even not recognize that option.

Comment 30 Jan Kratochvil 2011-06-29 09:40:46 UTC
*** Bug 701891 has been marked as a duplicate of this bug. ***

Comment 31 Clark Williams 2011-06-29 13:44:35 UTC
(In reply to comment #29)
> BTW, the ,ptmxmode=0666 addition should probably be added together with
> ,newinstance only on >= 2.6.29 kernels, if /dev/ptmx is a symlink only for
> those kernels, the mode of /dev/pts/ptmx doesn't matter on older kernels and
> those might even not recognize that option.

So here's my question: When the doc's are talking about the symlink/bind-mount, it's not clear if they want the link/mount to be only in the container (the mock chroot in this case) or in both the container and the main mount instance. My thought would be that I could just setup the devpts mount and symlink inside the chroot and not worry about how the system mountpoint is mounted, but I'm not certain. 

Thoughts?

Comment 32 Jakub Jelinek 2011-06-29 13:58:31 UTC
I don't understand the question.  If you use ,newinstance in the mock chroot, of course it only matters how dev/ptmx in that chroot looks like, it is irrelevant how it looks like in other chroots or in /.
I bet the kernel implementation will create new pts in a newinstance only if you work on the ptmx device from that instance, any other device with the same major/minor results in pts being created in the single devpts instance (usually the system /dev/pts is not mounted with ,newinstance and so appears there).
But glibc doesn't try to open /dev/pts/ptmx, but /dev/ptmx, so a symlink or bind mount of /dev/pts/ptmx to /dev/ptmx in the chroot achieves that open on /dev/ptmx opens the same inode as opening /dev/pts/ptmx.
So IMHO you really want:
  if kernel >= 2.6.29; then
    create /dev/ptmx -> pts/ptmx symlink
    add ",newinstance,ptmxmode=0666" to mount options for devpts mount
  else
    create /dev/ptmx device
  fi
The reason why 1.1.8 (or whatever mock used ,newinstance on >= 2.6.29 and always
created /dev/ptmx -> pts/ptmx symlink) didn't work on very old kernels is that
/dev/pts/ptmx didn't exist.

Comment 33 Clark Williams 2011-06-29 14:29:23 UTC
Ok, I couldn't tell if there was some sort of interaction inside the kernel between instances. 

I've got a branch I'm working on that will do the symlink/newinstance combo and if it passes smoke testing I'll see about getting something out for updates-testing soon.

Comment 34 Clark Williams 2011-08-17 00:53:12 UTC
mock-1.1.12 has the newinstance option plus symlink logic. Does it fix your issue.

Comment 35 Jan Kratochvil 2011-08-17 17:55:41 UTC
I can confirm with mock-1.1.12-1.fc14.noarch and
  mock -r epel-5-x86_64 --shell
GDB runtest works, thanks.  In some mock version before it did not work.

Comment 36 Clark Williams 2011-08-17 20:09:17 UTC
Excellent. I'm closing this one out.


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