rm shouldn't require /proc to be mounted

Bug #192239 reported by Adam Conrad on 2008-02-15
6
Affects Status Importance Assigned to Milestone
coreutils (Debian)
Fix Released
Unknown
coreutils (Ubuntu)
High
Unassigned
Hardy
High
Unassigned

Bug Description

Binary package hint: coreutils

When upgrading the buildd chroot tarballs, I got errors such as:

rm: cannot remove `/var/lib/dpkg/tmp.ci/control': Function not implemented
dpkg: error processing /var/cache/apt/archives/dash_0.5.4-6ubuntu1_ia64.deb (--unpack):
 subprocess rm cleanup returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/dash_0.5.4-6ubuntu1_ia64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Mounting /proc and trying again seemed to resolve the issue, but this is the first time I've ever seen such behavior.

In the past, I've filed (and fixed) bugs on packages in base that would bomb postinsts if /proc wasn't mounted, so it seems to be a pretty nasty regression that coreutils now depends on /proc.

Adam Conrad (adconrad) wrote :

This is reroducible with the simple test case below:

root@ross:/tmp# mkdir -p foo/bar/baz
root@ross:/tmp# touch foo/bar/baz/ungh
root@ross:/tmp# rm -rf foo/
rm: cannot remove `foo/bar': Function not implemented

Changed in coreutils:
importance: Undecided → High
Adam Conrad (adconrad) on 2008-02-15
description: updated
Changed in coreutils:
status: Unknown → New
Colin Watson (cjwatson) on 2008-03-20
Changed in coreutils:
assignee: nobody → james-w
James Westby (james-w) wrote :

Hi,

I'm just dumping a few notes in to the bug so that
I don't lose them.

Firstly, the linked Debian bug has some good
analysis of the problem.

I found a couple of possibly related links:

http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/6839
http://<email address hidden>/msg07872.html

James

Changed in coreutils:
status: New → Won't Fix
Matthew Lye (matthew.lye) wrote :

Confirmed again by me, test case reproducible as above.

Changed in coreutils:
status: New → Confirmed
Changed in coreutils:
status: New → Confirmed
C de-Avillez (hggdh2) wrote :

upstream has this commented at http://lists.gnu.org/archive/html/bug-coreutils/2008-08/msg00149.html. It can be summarised as:

"naruto canada" <address@hidden> wrote:
> On 8/19/08, Jim Meyering <address@hidden> wrote:
>> "naruto canada" <address@hidden> wrote:
>>> Starting from coreutils-6.3.tar.bz2 upward, when compiled against
>>> glibc-2.5.1,
>>> "rm" requires /proc mounted else this error "cannot remove `...':
>>> Function not implemented" is triggered.
>>
>> I reworked remove.c to use the then-new *at functions (openat, statat,
>> etc.) and when those kernel functions are not available, the code
>> falls back on using /proc-based emulation, when possible.
>> There's a still older approach (lib/save-cwd.c), which is what
>> earlier versions of coreutils use.
>>
>> If you're stuck using glibc-2.5.x, can you stick with
>> the older version of coreutils, too?
>
> That's what I did.
>
> How about newer glibc-- 2.6 upwards? I've not tried them yet.

With a new enough kernel (including openat et al syscalls),
it should work with any glibc version that provides the
wrappers and declarations. I don't remember off hand which
was the first.

James Westby (james-w) wrote :

I don't think we are going to do anything about this now unfortunately.

Almost all supported releases now have new enough kernels, so there is
little incentive for future development, and the cost is quite high.

Thanks,

James

Changed in coreutils (Ubuntu):
status: Confirmed → Won't Fix
Changed in coreutils (Ubuntu Hardy):
status: Confirmed → Won't Fix
Changed in coreutils (Ubuntu):
assignee: James Westby (james-w) → nobody
Changed in coreutils (Ubuntu Hardy):
assignee: James Westby (james-w) → nobody
Changed in coreutils (Debian):
status: Won't Fix → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.