[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#652946: busybox tar fails to copy filesystem.squashfs

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

		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

				db_progress STEP 1 <&4
		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 

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" 

> Thanks,
> /mjt

Thank you very much!! Debian is just great :)

Attachment: target.tar.gz
Description: Binary data

Reply to: