Bug#652946: busybox tar fails to copy filesystem.squashfs
Um. This is just insane. The bug is filed 22-Dec 2011,
today is 09-Jul 2012, you have the actual cause, and it
is still open, and the maintainers of suspected package
(busybox) knows nothing about it... :(
Okay.
Rui, you found the root cause of this issue, it is there:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652946#15
The problem is that during extraction, target directory
var/lock exists, and the installer tries to replace it
with something else (I guess a symlink).
Busybox tar does not try to remove directories in this
case, to be replaced with files. So it stops there,
treating it as fatal error, and does not extract remaining
files, creating issues for the system running later.
Whenever it is a bug in busybox tar or not is an open
question. POSIX does not specify whenever it should do
that or not. GNU tar tries to rmdir() the existing
file if unlink()ing it returned EISDIR, and will fail
only if the directory is non-empty. Ofcourse this rmdir
can be added to busybox tar too, it is rather trivial.
But this is not the point.
The point is the presence of var/lock directory in the
target system. It should not be there to start with.
We're extracting a whole set of directories, and any
existing directory in the target which clashes with
a file in the archive we're extracting may break the
extraction with any tar implementation, not just
busybox one. Ie, always extract to empty target
directory.
Now, I've no idea how this live system works, so I can't
say more.
Besides, I verified - busybox tar will correctly return
failure (and write accutate reason to stderr) in this
case. So something else in the live installer should be
broken too -- the part which loses error messages and
non-zero status codes.
So, to sum it all: it is a bug in the live installer,
it a) calls tar incorrectly (losing exit code and stderr)
and b) does not verify that the target directory is empty
or at least has sane content.
Thanks,
/mjt
Reply to: