Package: fakechroot
Version: 2.19-3.2
Severity: grave
Justification: renders package unusable
Control: block -1 by 915559
Hi,
currently, it is not possible to use the mv(1) tool from coreutils
within fakechroot. Since mv is also used in the dash and apt postinst
scripts, this means that:
- fakechroot is unfit for a debootstrap-like scenario
- shell scripts using mv will not work inside fakechroot
Since one of the main uses of fakechroot is to be used together with
debootstrap and since the mv tool is such an essential utility, I'm
marking this bug with RC severity.
Steps to reproduce:
$ fakechroot fakeroot -s fakeroot.state debootstrap --variant=fakechroot
unstable debian-unstable
[...]
W: Failure while configuring required packages.
W: See /home/josch/debian-unstable/debootstrap/debootstrap.log for details
(possibly the package dash is at fault)
And from the log:
Setting up dash (0.5.10.2-5) ...
No diversion 'diversion of /bin/sh by bash', none removed.
Adding 'diversion of /bin/sh to /bin/sh.distrib by dash'
mv: cannot move '/bin/sh.tmp' to '/bin/sh': No such file or directory
dpkg: error processing package dash (--configure):
installed dash package post-installation script subprocess returned error
exit status 1
To reproduce it manually:
fakechroot fakeroot -s fakeroot.state chroot debian-unstable mv /bin/sh.tmp
/bin/sh
mv: cannot move '/bin/sh.tmp' to '/bin/sh': No such file or directory
The problem is, that coreutils directly invokes the renameat2 systemcall
instead of its glibc wrapper function. fakechroot cannot intercept
system calls, so the bare renameat2 call will be executed. From wrapping
the above in strace:
[pid 8332] renameat2(AT_FDCWD, "/bin/sh.tmp", AT_FDCWD, "/bin/sh",
RENAME_NOREPLACE) = -1 ENOENT (No such file or directory)
As one can see, the paths did not get adjusted by fakechroot.
There is a bug against coreutils which backports a patch from coreutils
upstream that fixes this problem. The issue is tracked in #915559.
Thanks!
cheers, josch
