Hi Michael,
On Mon, Jul 09, 2012 at 11:11:24PM +0400, Michael Tokarev wrote:
> 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... :(
I think we didn't know for sure that busybox was the to blame. Daniel
said the error is in busybox, not a busybox error.
Because this bug is hard to trace (got to build and rebuild several live
images), lack of time, etc, time passed... Anyway, as you pointed out,
it's not busybox. Thank you.
>
> 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.
Thanks again for clearing the fog here :)
Following your pointers I've put a "sleep 2000" in
live-installer.postinst just _before_ the line "mkdir -p /target" and
then I've open tty2 console in debian-installer to check what was in
/target (see below).
>
> 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.
I think the problem about redirecting the error messages is because
live-installer.postint extracts the filesystem in background with exec
4. The relevant part of postinst:
eval ${SUPPORT}_prepare
STEPS=$(eval ${SUPPORT}_count)
db_progress INFO live-installer/progress/copying
COUNT=0
OLD_IFS=$IFS
mkdir -p /target
exec 4>&0
tar c . | \
(chdir /target && tar xv) | \
(
while read line; do
COUNT=$(($COUNT + 1))
CURRENT=$(($COUNT * 100 / $STEPS))
[ x$CURRENT = x$LAST_UPDATE ] && continue
LAST_UPDATE=$CURRENT
db_progress STEP 1 <&4
done
)
exec 0>&4
I don't know if adding a "2>" or a "|tee -a" would work. It's a question
of trying it. It would really help in the future.
>
> 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 for this, I really thought it was something about links or
hardlinks in the squash filesystem all the time. Turns out that is
/target that is not empty when the extraction happens!
As I've said above, I've put a "sleep 2000" before "mkdir -p /target"
and SURPRISE (for me at least): /target, which I thought should be empty
because it is apparently created after partman has formated the
partitions (so I assumed completely empty), is _not_ empty:
root@quartor:~# tar tf target.tar.gz
./
./etc/
./etc/fstab
./lost+found/
./media/
./media/cdrom0/
./media/cdrom
./var/
./var/lock/
./var/run/
I've attached the tar file with what I've found in /target/ before the
extraction began.
I presume this must be something that line "eval ${SUPPORT}_prepare"
does.
>
> Thanks,
>
> /mjt
Thank you very much!! Debian is just great :)
Attachment:
target.tar.gz
Description: Binary data