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

Re: Possible multistrap fix.

On Sun, 1 Nov 2009 12:10:43 +0000
Neil Williams <codehelp@debian.org> wrote:

> A simple check appears sufficient, from outside the chroot, prior to
> unpacking:
> #!/usr/bin/perl
> $dir = "/path/to/top/of/chroot/"
> if (-l "${dir}lib64" ) {
> 	$r = readlink "${dir}lib64";
> 	if ($r =~ m:^/:)
> 	{
> 		my $old = `pwd`;
> 		chomp ($old);
> 		unlink "${dir}lib64";
> 		chdir ("$dir");
> 		symlink "./lib", "lib64";
> 		chdir ("$old");
> 	}
> }
> (The chdir is necessary, it needs to be lib64 -> ./lib not lib64
> -> /path/to/chroot/lib otherwise chroot fails to execute /bin/bash but
> that's just a side-effect of using the perl symlink function instead
> of calling ln directly.)
> Possibly run the find test too, just to catch any new cases. 
> Thankfully, dpkg -e doesn't clobber this fix:

Actually, it does in actual usage - the test is unpacking over the top
of an existing unpacked package. When it's the first unpacking, dpkg
(or tar) removes the pre-existing symlink.

This makes the multistrap patch more complex but it does now work.

Until the other bug in dpkg/tar/libc6 is fixed, you may see this in the
multistrap output:

I: Extracting libc6_2.7-18_amd64.deb...
 -> Processing conffiles for libc6
ERR: lib64 -> ./lib symbolic link clobbered by libc6
INF: lib64 -> /lib symbolic link reset to ./lib.

from version 2.0.4 onwards.

The check is done immediately after unpacking each package.

If, for some reason, the symlink is still bad at the end, multistrap
will warn you:

ERR: ./lib64 -> /lib symbolic link reset to ./lib after unpacking.
ERR: Some files may have been unpacked outside $dir!


Neil Williams

Attachment: pgppadXxaNVRd.pgp
Description: PGP signature

Reply to: