Summary: | openvz-kernel & coreutils-6.12-r1: touch: setting times [...] Bad address | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Covington <cov> |
Component: | [OLD] Core system | Assignee: | Peter Volkov (RETIRED) <pva> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | drobbins, gbf, loki_val, snaury, vserver-devs+disabled, yuriy.glukhov |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 224483 | ||
Bug Blocks: |
Description
Christopher Covington
2008-07-29 14:59:29 UTC
*** This bug has been marked as a duplicate of bug 224483 *** Re-opening to track this issue seperately from the touch: setting times of [...] Function not implemented issue. Re-assigning to pva & vserver; odd unsupported kernels are their domain. A short introduction to this bug: sys-apps/coreutils-6.12 would fail on 'old' kernels with touch: setting times of [...] Function not implemented issue. Mr. Covington's kernel fails differently: touch: setting times [...] Bad address The fix for the first issue was put into coreutils-6.12-r1. The second issue is, AFAICT, unique to this bug and not encountered by anyone before. We have reports of 2.6.16 and 2.6.21 being fixed with this. The only other report from a 2.6.18 user was of "Function not implemented". coreutils-6.12-r1.ebuild did not fix the problems for a full ~amd64 and ~x86 stage1 build under OpenVZ. Same "bad address" issue. The kernel being used is a RHEL5-based 2.6.18 kernel from the OpenVZ team - 2.6.18-53.1.19.el5.028stab053.14, their stable kernel. When I use a newer "unstable" OpenVZ kernel the problem disappears and touch works fine. I don't think the problem relates to OpenVZ but rather that OpenVZ allows a decoupling between the kernel version and the linux-headers version that everything is built against under Gentoo. Typically under Gentoo one runs a kernel that's newer than linux-headers. In an OpenVZ environment this isn't necessarily true. This is a bug that should be fixed as it would break Gentoo installs into virtualized containers environments like OpenVZ and Linux VServer. Also, please note that the older coreutils which worked (6.10) also made this utimensat call which failed, but the older coreutils handled this failure and thus did not produce a non-zero exit code. It actually looks like touch is working "fine" in 6.10 - the file is created - but badness is happening by trickling the utimensat failure up to the exit code. But I have not really researched what they are trying to do with utimensat and if the call is important in the context of what touch is trying to do - I just did an strace and saw utimensat failing in 6.10 as well but touch itself worked fine due to a zero error code (and no error message). Thank you guys. Should be fixed in openvz-sources-2.6.18.028.057.2. Fantastic! Do you have any information from the OpenVZ team that confirmed this as an upstream bug? Any OpenVZ bug #, etc? I am interested in researching this issue in OpenVZ to gain more understanding of it. Regards, Daniel (In reply to comment #8) > Do you have any information from the OpenVZ team that confirmed this > as an upstream bug? Any OpenVZ bug #, etc? I am interested in researching this > issue in OpenVZ to gain more understanding of it. The issue is simple, they backported utimensat implementation, but they forgot to apply later Linus patch to make it workable with filename descriptors. It's pity that I didn't manage to fix this issue myself understanding all above. And of course I've contacted upstream: http://bugzilla.openvz.org/show_bug.cgi?id=970 BTW, I'm going to stabilize this kernel on x86 on Monday and maybe around that time and amd64 too so if you notice any problem, please, tell me that. thanks for your work on this. *** Bug 266735 has been marked as a duplicate of this bug. *** Why was my bug marked as a duplicate of this bug? My bug is about coreutils-7.1, not coreutils-6.12. This bug is resolved and fixed, my bug bit me just several hours ago. Which means either this bug is not resolved and not fixed, or my bug is not a duplicate of this bug. Alexey: the problem you are experiencing is a kernel bug. it is fixed by upgrading the kernel, as described in the comments on this bug. that you cant change that, is just tough luck... but it's quite a stretch to demand that we do something about it. sorry. *** Bug 267669 has been marked as a duplicate of this bug. *** Since this is the bug everyone gets referred to, I'll just post a work-around here: As a work-around, do: cd / wget http://tinderbox.dev.gentoo.org/default-linux/x86/sys-apps/coreutils-6.10-r2.tbz2 tar -xjf coreutils-6.10-r2.tbz2 <insert praying> If this works, you should now mask >=sys-apps/coreutils-6.12 and do: emerge -1 coreutils (to get your system into a sane state again) *** Bug 268372 has been marked as a duplicate of this bug. *** Now that coreutils < 7 have been removed from portage, does any workaround remain? The binpkg for 6.10 is gone, as are the coreutils-6 ebuilds in portage. you can find old coreutils ebuilds here: http://sources.gentoo.org:80/viewcvs.py/gentoo-x86/sys-apps/coreutils/?hideattic=0 I just marked 2.6.27 stable, so not workaround, but fix is to use this kernel. Thanks. I can't change kernel, since that bought VPS -- so just do rm /bin/touch && ln -s /bin/bb /bin/touch fixes troublie with touch. then why are you *paying* someone who is providing *broken* software to you ? sounds like you arent shopping smart. at any rate, not a bug in coreutils, so base-system cc -> gone |