Processed: Re: Bug#464118: rm -r broken: Function not implemented
Processing commands for [EMAIL PROTECTED]: severity 464118 important Bug#464118: rm -r broken: Function not implemented Severity set to `important' from `grave' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
severity 464118 important thanks On 26/02/08 at 20:22 -0500, Michael Stone wrote: Reproducing this is fairly easy if you install sid into a qemu image then install the 2.6.8-4-686 kernel from sarge, as long as your machine doesn't have puffed up and knocked over capacitors. :-) So the etch kernel is not affected? If not, it's not RC, I think, since we don't support sarge-lenny upgrades. In the meantime, I'm downgrading the severity, which should allow coreutils to get into testing. We can always increase it back if it's really considered RC. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On Fri, Feb 15, 2008 at 05:09:31PM -0700, you wrote: So, this seems to be restricted to either older kernels, or kernels with a specific config. Since my last email I've had my primary development machine die from bad capacitors, replaced it, put a new test qemu environment together, tried a variety of kernels working backward from 2.6.24, 2.6.18, 2.6.17, 2.6.16, and finally had a failure with 2.6.8. (woo-hoo!) I compiled ran the test.c I attached earlier in the bug log, and it fails with the same function not implmented error strace. In my mind, that suggests that this is a bug in the libc syscall emulation code rather than coreutils, and my inclination is to reassign to libc. Anyone have any other thoughts? (One other thought is that it should simply be downgraded since this shouldn't fail on any kernel released since etch, and we don't support skipping releases.) (As for reassigning, the logic is that coreutils checks to see if unlinkat(2) is present in libc, and it is, so coreutils uses that rather than its own emulation code. That function works at build time, and works at run time if /proc is mounted. If proc is unmounted, unlinkat(2) suddenly fails. I don't think it's reasonable to expect coreutils to work around that. I do think that coreutils *would* work around that if unlinkat(2) wasn't present.) Reproducing this is fairly easy if you install sid into a qemu image then install the 2.6.8-4-686 kernel from sarge, as long as your machine doesn't have puffed up and knocked over capacitors. :-) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
Adam Conrad [EMAIL PROTECTED] wrote: On Fri, Feb 15, 2008 at 07:16:12PM -0500, Michael Stone wrote: Could you send an strace from one of the non-working systems? That might be enough to figure out what's going wrong and whether it can be worked around. Attached. Thanks. Please double-check the version of the rm binary you used to create that strace output. When I try to reproduce the situation (no openat support and no /proc), the fchdir-based openat emulation works just fine. But I'm merely simulating the situation, and am actually running tests on a system with a recent kernel, so there may be other factors. That said, ... I used a version of rm from the trunk (i.e., post-coreutils-6.10) and comparing an strace of my working rm -r dir/ command to yours shows fundamental differences that make me think your version of rm is out of date. Maybe even from coreutils-5.9x. If you can confirm you're using something based on 6.10, please also attach config.status and lib/config.h. --- For the record, here's what I did: Simulate the lack of openat functions: ac_cv_func_openat=no ./configure make make check All tests passed. Next, pretend we don't have /proc/self/fd support either, by changing the openat-emulation code to use nonexistent /proc/self/FD: perl -pi -e 's,/proc/self/fd,/proc/self/FD,' lib/openat-proc.c \ tests/du/long-from-unreadable tests/rm/inaccessible That passed all tests, too, and gave the strace results that looked so different from yours. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
My thought is that glibc has some kind of fallback code if you use
unlinkat on a system that doesn't support it, and that's what's broken;
since these are all being compiled with the same glibc, the libc symbol
should always exist, no? Adam, could you try building/running the
attached? If it also fails, it ain't coreutils.
Mike Stone
#define _ATFILE_SOURCE
#include sys/types.h
#include sys/stat.h
#include stdlib.h
#include fcntl.h
#include stdio.h
#include dirent.h
main() {
char tempdir[] = testXX;
if (!mkdtemp(tempdir)) perror(error making tempdir);
if (chdir(tempdir)) perror(error changing to tempdir);
if (!open(foothingtoremove,O_WRONLY|O_CREAT,600)) perror(error making target file);
if (mkdir(foodirtoremove,700)) perror(error making target dir);
DIR *dirp = opendir(.);
if (dirfd == NULL) perror(error opening directory);
int err = unlinkat(dirfd(dirp), foothingtoremove, 0);
if (err 0) perror(error removing foothingtoremove);
err = unlinkat(dirfd(dirp), foodirtoremove, AT_REMOVEDIR);
if (err 0) perror(error removing foodirtoremove);
chdir(..);
rmdir(tempdir);
}
Bug#464118: rm -r broken: Function not implemented
Jim Meyering [EMAIL PROTECTED] wrote: For the record, here's what I did: Simulate the lack of openat functions: ac_cv_func_openat=no ./configure make make check All tests passed. Next, pretend we don't have /proc/self/fd support either, by changing the openat-emulation code to use nonexistent /proc/self/FD: perl -pi -e 's,/proc/self/fd,/proc/self/FD,' lib/openat-proc.c \ tests/du/long-from-unreadable tests/rm/inaccessible That passed all tests, too, and gave the strace results that looked so different from yours. Actually, Michael pointed out that your strace includes an fstatat call (failing with ENOSYS, no less), which suggests you're using a new-enough version. I dug a little deeper and think I have identified the problem. I suspect that your system has a working openat function and that coreutils detects it, but that your fstatat function always returns ENOSYS. The openat module's configure-time test checks only for the existence of the openat function. If that test succeeds on your system, yet it lacks fstatat, then that would explain what's happening. To support such a system you have a choice: 1) easy: turn off all openat support. i.e., build like this: ac_cv_func_openat=no ./configure 2) more work: add a configure-time test for a working fstatat, and if it's not available, link with the replacement function that is currently included unconditionally via the definition in openat.c. Since this is for a kernel that is old, but not *that* old, (i.e., the problem affects only the few kernels, that had incomplete openat support) spending time on #2 does not seem worthwhile to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
For what it's worth, the confusion in this bug log seems due to the fact that people testing succesfully clearly have /proc mounted. I spotted the same bug on the Ubuntu buildds today while mucking around inside chroots without /proc mounted: https://bugs.edge.launchpad.net/ubuntu/+source/coreutils/+bug/192239 ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On Fri, Feb 15, 2008 at 03:47:34PM -0700, you wrote: For what it's worth, the confusion in this bug log seems due to the fact that people testing succesfully clearly have /proc mounted. I spotted the same bug on the Ubuntu buildds today while mucking around inside chroots without /proc mounted: https://bugs.edge.launchpad.net/ubuntu/+source/coreutils/+bug/192239 It should certainly be easier to fix with a reproducable test case! Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On Fri, Feb 15, 2008 at 05:56:14PM -0500, you wrote: On Fri, Feb 15, 2008 at 03:47:34PM -0700, you wrote: For what it's worth, the confusion in this bug log seems due to the fact that people testing succesfully clearly have /proc mounted. I spotted the same bug on the Ubuntu buildds today while mucking around inside chroots without /proc mounted: https://bugs.edge.launchpad.net/ubuntu/+source/coreutils/+bug/192239 It should certainly be easier to fix with a reproducable test case! of course, I still can't reproduce it: annuminas:/tmp# find /proc /proc annuminas:/tmp# mkdir -p foo/bar/baz annuminas:/tmp# touch foo/bar/baz/ungh annuminas:/tmp# rm -rf foo/ annuminas:/tmp# find foo find: foo: No such file or directory annuminas:/tmp# Am I missing something? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On Fri, Feb 15, 2008 at 06:04:01PM -0500, Michael Stone wrote: of course, I still can't reproduce it: Am I missing something? Damn. I can tell you that I reproduced it on amd64, i386, powerpc, ia64, and sparc, and that it was a bare hardy --variant=buildd chroot (more or less) without /proc mounted. There's nothing proprietary about our buildd chroots, so I could make a tarball available to you if that would help. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
What we were missing here was kernel build and/or version, it seems. I vaguely remembered *not* seeing this on our hppa buildds and, on a hunch, went checking kernel versions. amd64, i386, powerpc, ia64, and sparc were all running 2.6.15, lpia was running 2.6.17, and hppa is running the latest 2.6.22-14-hppa32 from gutsy. On a hunch, I grabbed a buildd tarball and tried to reproduce this on my laptop (also running 2.6.22-14 from gutsy, but on i386), and couldn't reproduce it here locally either. So, this seems to be restricted to either older kernels, or kernels with a specific config. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On Fri, Feb 15, 2008 at 07:16:12PM -0500, Michael Stone wrote:
Could you send an strace from one of the non-working systems? That might
be enough to figure out what's going wrong and whether it can be worked
around.
Attached.
... Adam
execve(/bin/rm, [rm, -rf, foo/], [/* 12 vars */]) = 0
brk(0) = 0x8054000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fd5000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=7012, ...}) = 0
mmap2(NULL, 7012, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fd3000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1274092, ...}) = 0
mmap2(NULL, 1279600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e9a000
mmap2(0xb7fcd000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x133) = 0xb7fcd000
mmap2(0xb7fd, 9840, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fd
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e99000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e996b0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb7fcd000, 4096, PROT_READ) = 0
munmap(0xb7fd3000, 7012)= 0
brk(0) = 0x8054000
brk(0x8075000) = 0x8075000
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat64(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstatat64(AT_FDCWD, foo/, 0xbfdee29c, AT_SYMLINK_NOFOLLOW) = -1 ENOSYS
(Function not implemented)
lstat64(foo/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
unlink(foo/) = -1 EISDIR (Is a directory)
open(foo/, O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(3, F_GETFL) = 0x28800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW)
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 3 entries */, 4096)= 72
open(/proc/self/fd/3/bar,
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = -1 ENOENT (No such file
or directory)
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/proc/self/fd, 0xbfdedff0) = -1 ENOENT (No such file or directory)
rmdir(/proc/self/fd/3/bar)= -1 ENOENT (No such file or directory)
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/proc/self/fd, 0xbfdee050) = -1 ENOENT (No such file or directory)
write(2, rm: , 4rm: ) = 4
write(2, cannot remove `foo/bar\', 23cannot remove `foo/bar') = 23
write(2, : Function not implemented, 26: Function not implemented) = 26
write(2, \n, 1
) = 1
getdents64(3, /* 0 entries */, 4096)= 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
close(3)= 0
close(0)= 0
close(1)= 0
close(2)= 0
exit_group(1) = ?
Process 23930 detached
Bug#464118: rm -r broken: Function not implemented
Package: coreutils Version: 6.10-3 Severity: grave I installed this package, after which my entire system started to break due to problems caused in mkinitramfs and packages fail to install. /var/cache/apt/archives/coreutils_6.10-3_i386.deb After using a boot CD, chrooting and re-installing /root/coreutils_5.97-5.3_i386.deb rm -r was working as expected again. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (700, 'experimental'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages coreutils depends on: ii libacl1 2.2.45-1Access control list shared library ii libc62.7-6 GNU C Library: Shared libraries ii libselinux1 2.0.15-2+b1 SELinux shared libraries coreutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On 05/02/08 at 10:01 +0100, Marc Leeman wrote:
Package: coreutils
Version: 6.10-3
Severity: grave
I installed this package, after which my entire system started to break
due to problems caused in mkinitramfs and packages fail to install.
/var/cache/apt/archives/coreutils_6.10-3_i386.deb
After using a boot CD, chrooting and re-installing
/root/coreutils_5.97-5.3_i386.deb
rm -r was working as expected again.
Hi Marc,
rm -r works fine here:
*** [EMAIL PROTECTED]:/tmp/cu$ mkdir -p t/{a,b}/{a,b}
*** [EMAIL PROTECTED]:/tmp/cu$ touch t/{a,b}/{a,b}/f
*** [EMAIL PROTECTED]:/tmp/cu$ find t
t
t/a
t/a/a
t/a/a/f
t/a/b
t/a/b/f
t/b
t/b/a
t/b/a/f
t/b/b
t/b/b/f
*** [EMAIL PROTECTED]:/tmp/cu$ rm -r t
*** [EMAIL PROTECTED]:/tmp/cu$ echo $?
0
and update-initramfs works fine as well:
*** [EMAIL PROTECTED]:/tmp/cu$ sudo update-initramfs -k 2.6.23-1-686 -u
update-initramfs: Generating /boot/initrd.img-2.6.23-1-686
*** [EMAIL PROTECTED]:/tmp/cu$ echo $?
0
Could you point to something specific that is/was broken for you?
The output of strace rm -r ... could be useful too.
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On 05/02/08 at 10:01 +0100, Marc Leeman wrote: rm -r was working as expected again. On second thought, it might be the same problem as the mips build failure (the one seen on the buildds). Which filesystem are you using ? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464118: rm -r broken: Function not implemented
On Tue, Feb 05, 2008 at 10:01:40AM +0100, Marc Leeman wrote: I installed this package, after which my entire system started to break due to problems caused in mkinitramfs and packages fail to install. I need a lot more information that this; it's certainly the case that it works fine here on other people's systems (so can't be duplicated). Do you have any sample output? Lucas Nussbaum asked some other questions in another email. You can do something like mkdir /tmp/t dpkg-deb -x coreutils_6.10-3_i386.deb /tmp/t /tmp/t/bin/rm to run the 6.10 binary without installing the 6.10 package. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
