Re: chroot and ia32libs combined
On Tue, 2006-09-05 at 07:52 -0500, Seb wrote:
> On Mon, 04 Sep 2006 23:38:41 -0500, Owen Heisler wrote:
> > On Mon, 2006-09-04 at 14:34 -0500, Seb wrote:
> >> I'm trying to create a chroot in a AMD64 Debian system, following a
> >> how-to posted from http://www.debian-administration.org/articles/356.
> >> However, I'm not comfortable messing with my main system config files
> >> (like /et/ld.so.conf), which the how-to suggests. For other reasons, I
> >> also had the ia32-libs package installed, so I thought I could avoid
> >> messing my /etc/ld.so.conf and thought that the chroot should be able
> >> to use the libraries from ia32-libs. I can see I already have the
> >> /lib/ld-linux.so.2 link. Is this sensible? if not, is there some
> >> alternative?
> >
> > This is so you can use the 32-bit libraries in the 64-bit system. It is
> > unnecessary if you do all your 32-bit stuff in the chroot.
>
> I see, but in case I want to run the 32 bit apps from the 64 bit system,
> is it enough to have the ia32-libs package installed, or is it absolutely
> necessary to add those lines in /etc/ld.so.conf? Perhaps I should ask
> whether you can run your apps in the chroot as comfortably as you can from
> your 64 bit system.
I'm not sure about that. I just wanted to make as few changes as
possible to my system (/var/chroot/* & /etc/fstab).
I use schroot to run stuff in the chroot. Just "schroot -p <command>",
unless you have multiple chroots, then add the -c option. It works
nicely.
It doesn't look like you mentioned whether you are using Sarge. If so,
the schroot package is unavailable. Then you would want to use dchroot.
But dchroot has a problem with changes in the login package (in the
chroot); if you get an error, that's probably what the problem is. You
can get around this by running the command indirectly, through a script
in the chroot ("dchroot -d <script-in-chroot>"). But that isn't really
a "comfortable" way to use your chroot! When I was running Sarge, I
just installed Sarge in the chroot, told aptitude to hold the login
package to that version, then upgraded the chroot to Etch. Or maybe
schroot is available from backports. Hopefully you're using Etch, so
this isn't a problem.
Reply to: