| Summary: | app-emulation/qemu-user-1.2.2: epoll syscall generates events for unregistered file descriptors inside arm chroot | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Kevin Wilson <kwilson> |
| Component: | Core | Assignee: | Luca Barbato <lu_zero> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | dev-portage, kripton, kwilson, qemu+disabled |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | ARM | ||
| OS: | Linux | ||
| URL: | http://lists.gnu.org/archive/html/qemu-devel/2011-02/msg01887.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 508098 | ||
| Bug Blocks: | |||
| Attachments: |
'git bisect log' output
output of 'runtests.sh' in portage git repo for commit b986bcdd49c5523ffe6972377071d556a819c776 workaround: disable epoll in portage |
||
|
Description
Kevin Wilson
2013-01-10 23:26:34 UTC
Created attachment 335122 [details]
'git bisect log' output
My apologies. The original post should read "I had been using the previous stable version, portage-2.1.11.9, ...". To be clear: portage-2.1.11.9 worked, but later versions do not. Created attachment 335126 [details]
output of 'runtests.sh' in portage git repo for commit b986bcdd49c5523ffe6972377071d556a819c776
(In reply to comment #0) > >>> Installing (1 of 1) sys-libs/ncurses-5.9-r2 > qemu: Unsupported syscall: 373 This looks more like a fault of qemu than a portage bug. How could it be acceptable to ignore a syscall and just print a warning message like this? (In reply to comment #4) > (In reply to comment #0) > > >>> Installing (1 of 1) sys-libs/ncurses-5.9-r2 > > qemu: Unsupported syscall: 373 > > This looks more like a fault of qemu than a portage bug. How could it be > acceptable to ignore a syscall and just print a warning message like this? I thought so too. I don't remember whether or not the warnings appeared with portage 2.1.11.9. However, the merge failures are new, and the change to portage has rendered my build setup effectively useless. I would really appreciate some sort of workaround until the combination of qemu and portage works again. Created attachment 335244 [details, diff]
workaround: disable epoll in portage
(In reply to comment #6) > Created attachment 335244 [details, diff] [details, diff] > workaround: disable epoll in portage I applied this patch to portage-2.1.11.31 and 'emerge' finishes cleanly again. Thanks! I'll add it to my local overlay. FWIW, I still see the qemu syscall warnings: >>> Installing (1 of 1) sys-libs/gpm-1.20.6 qemu: Unsupported syscall: 373 qemu: Unsupported syscall: 373 >>> Auto-cleaning packages... (In reply to comment #0) > Steps to Reproduce: > 1. Install qemu-user with qemu_user_targets_arm enabled. What version of qemu-user is this? Note that qemu-user is now masked, and app-emulation/qemu with QEMU_USER_TARGETS is the replacement, as recently announced: > Subject: [gentoo-dev] app-emulation/qemu-user mask > From: Doug Goldstein <cardoe@gentoo.org> > To: gentoo-dev@lists.gentoo.org, gentoo-dev-announce@lists.gentoo.org > > Just wanted to give everyone a heads up. app-emulation/qemu provides > all the functionality of app-emulation/qemu-user without all the > outstanding security bugs and issues the package has. For users using > a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I > presently use an arm chroot with app-emulation/qemu. Should there > truly be a missing feature, open a bug and I'll fix it. The only item > I'm aware of that app-emulation/qemu does not have is the binfmt > initscript. But I plan on adding that to the unstable version shortly. > > If there are no objections for 30 days, I'll send a treecleaner notice > in 30 days and remove it 30 days after that (60 days from now). This issue exists because app-emulation/qemu-user is out of date and not updated. This is exactly one of the reasons why I've masked it and recommended people switch to app-emulation/qemu. I'm using app-emulation/qemu-user-1.1.0-r1. I'll switch to qemu and retain the qemu-binfmt init script. Thanks for your attention. (In reply to comment #0) > File "/usr/lib/portage/pym/portage/util/_eventloop/EventLoop.py", line > 259, in iteration > x = event_handlers[f] > KeyError: 900929539 I've experienced this problem with qemu-user-1.2.2, and I've committed the following workaround for portage: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=071440cc30cc5a625317d5bd47e86c2bfdd8a940 It seems to be a harmless quirk if we simply ignore the extra events that are generated. Apparently the "qemu: Unsupported syscall: 373" messages are for some other syscall, probably syncfs, since the above patch would not work unless epoll was also working. qemu-user has been removed from the tree as its functionality has been superseded by the combined app-emulation/qemu package. if you find the qemu package does not support something that the qemu-user package did, please file a new bug explicitly detailing things so we can get it added. |
