chroot from x86_64 into x86 possible?

Dj_Jestar

Dj_Jestar

Dj_Jestar

Caporegime
Joined
18 Oct 2002
Posts
29,493
Location
Back in East London
I've mounted a slave device which is from an x86 machine, on an x86_64 machine within the intent of chrooting and fixing the problem(s) but keep getting:
Code: 
chroot: cannot run command `/bin/bash': No such file or directory
as the result. I suspect this is because the host is x86_64 and the slave/guest is x86.. is this the case? Is there anything I can do to chroot like this?

I suspect this is the case because of:
Code: 
localhost ~ # ldd /bin/bash
        linux-vdso.so.1 =>  (0x00007fff51dff000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x00007fdd497bd000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fdd495b9000)
        libc.so.6 => /lib/libc.so.6 (0x00007fdd49271000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdd49a19000)

Many thanks.
 
Mmmm, I imagine you would run into linking problems on such things, just because of the architecture. I don't have a good way round it, but a better time-saving way of doing it might just be to do your chrooting from an x86 environment, like a live-CD.
 
yeah, I would prefer that.. but the machine in question doesn't have a CD-ROM :(

I've discovered that a lot of files in /lib on the guest are missing, so I'm going for a full stage3 replacement anyway.
 
In theory it should be possible as you can create an x86 chroot in a x86_64 bit system.....

Never made it work though so i cant really help :(
 
should work fine, chrooting into my i686 gentoo root fs and running bash works on my gentoo x86-64 box without any issues.

ldd is just going to try loading using your existing libdl/ld-linux rather than the one in the chroot dir

Do the .so's required by the 32-bit bash exist in /lib in the filesystem/dir you're chrooting into?

eg :
Code: 
# cd /mnt/gentoo.i686
# for i in $(objdump -p bin/bash|grep NEEDED|awk '{print $2}');do objdump -f lib/$i;done

lib/libncurses.so.5:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000106f0

lib/libdl.so.2:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00000a30

lib/libc.so.6:     file format elf32-i386
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00016770
if these .so's are corrupt/don't exist then you'll get the 'No such file or directory' from chroot. also check if your dev directory contains valid device nodes for null/console/tty. mount --bind /dev /mnt/chroot/dev is easiest
 
Last edited:
nah, it was the i586 machines /lib that was missing loads of stuff. Not sure what happened but I think someone tried to update world for the first time in 2 years and it's now fubar.

Now I've got portage and stage3 tarballs extracted, it's complaining because the installed version of glibc and gcc are *old* (despite stage3!?) so am going old school and upgrading those with ebuild, and if that fails.. make.

If it wasn't so important to keep the disk/data I'd have nuked it a long time ago :/
 
Indeed :) Well on it's way to resolution now though, just compiling gcc, glibc and latest version of portage and it'll be good to go :)
 
You must log in or register to reply here.
Back
Top Bottom