Bug 683111
Summary: | /dev/tty and /dev/ptmx are not created in epel-5 based chroots on F14 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Gagne <gagnec> |
Component: | mock | Assignee: | Clark Williams <williams> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 14 | CC: | dcantrell, gholms, jakub, jan.kratochvil, mebrown, williams |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | mock-1.1.10-1.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-08-17 20:09:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Chris Gagne
2011-03-08 15:36:19 UTC
Chris, I'm looking at adding them back when --shell is the active command. Will that do what you need? Hi Clark, Would that work when --chroot is used as well? If so I think that would cover our use cases. Thanks, Chris 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? Yes. I'll test whatever you have. 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. 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. 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.
Created attachment 483552 [details]
Patch to create tty and ptmx symlinks on Fedora and EL6 hosts
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) 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.
Clark, that works. Thank you. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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. 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 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 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 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 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 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). 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. 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. 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. 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. 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. 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? With mock 1.1.10 on a 2.6.35 kernel (F14 host, RHEL5 chroot) I'm still seeing this too. 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. 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. 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. *** Bug 701891 has been marked as a duplicate of this bug. *** (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? 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. 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. mock-1.1.12 has the newinstance option plus symlink logic. Does it fix your issue. 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. Excellent. I'm closing this one out. |