:: Re: [DNG] chroot sees wrong version…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
To: dng
Subject: Re: [DNG] chroot sees wrong version of libc
Didier Kryn <kryn@???> writes:
> Le 28/04/2016 21:23, Rainer Weikusat a écrit :
>> as manually running debootstrap in
>> two steps on the same system doesn't do anything the single-step
>> debootstrap wouldn't also do
>     But it's not the same system.

It is the same system: Same CPU, same other hardware etc.

              Do  the  initial  unpack  phase  of  bootstrapping  only,
              for example if the target architecture does not match the
              host architecture.

The idea behind that is that the files making up the new filesystem tree
are downloaded but none of the downloaded code is executed (as it won't
run if it was compiled for a different kind of CPU). The downloaded
files can then be transported to the target system and the second stage
can then be started (on the right CPU). But that's not an issue here as
a system which has the wheezy i686 C library installed will be capable
of running i386 code (except in very unlikely circumstances).

After the files were downloaded (and unpacked), the configure stage of
installing the packages has to run chrooted to the top-level directory
of the system installation supposed to be created so that it sees the
downloaded libraries instead of the ones installed on the host
system. For the given case, this would enable the downloaded /bin/bash
to run as it would be combined with the downloaded C library (which
defines GLIBC_2.15) instead of the wheezy C library (which doesn't as
it's based on glib 2.13).

debootstrap is a script which uses a variable named WHAT_TO_DO to
specify the steps which should be executed by an invocation. The default

WHAT_TO_DO="finddebs dldebs first_stage second_stage"

using --foreign changes this to

    if [ "$PRINT_DEBS" != "true" ]; then
        WHAT_TO_DO="finddebs dldebs first_stage"

and --second-stage to