| View previous topic :: View next topic |
| Author |
Message |
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
 Posted: Sun Mar 23, 2025 10:28 am Post subject: Using intel's sde to chroot into a ROOT. |
 |
|
I'm trying to chroot into an x86-64 (built using -march=icelake-client) system from another x86-64 system who's CPU has incompatible instructions to icelake-client (znver1). The incompatibility is avx512 -- even qemu softmmu has not implemented it, so I'm using Intel's SDE which IS able to execute these binaries at least.
However I'm not able to chroot using it to the this ROOT. I copied over the SDE (which is a directory) to ROOT and --
| Code: | | chroot /usr/x86_64-mypl-linux-gnu/ /sde64 -- /bin/bash |
However I'm getting --
| Code: | | traps: sde64[229146] trap invalid opcode ip:7f56db09475d sp:7ffd55266fa8 error:0 in ld-linux-x86-64.so.2[1e75d,7f56db077000+2c000] |
So the ROOT's ld-linux-x86-64.so.2 is being used to execute sde64; also sde64 links against libc. So what I did is copied the host's libc.so.6 and ld-linux-x86-64.so.2 to /znver1/ of ROOT and --
| Code: | | chroot /usr/x86_64-mypl-linux-gnu/ /znver1/ld-linux-x86-64.so.2 --library-path /znver1/ ./sde64 -icl -- /bin/bash |
which AGAIN results in
| Code: | | Illegal instruction (core dumped) |
| Code: | | traps: pinbin[229213] trap invalid opcode ip:7f92d3d3775d sp:7fffca461648 error:0 in ld-linux-x86-64.so.2[1e75d,7f92d3d1a000+2c000] |
Interestingly the sde64 binary itself works. For e.g --help works.
I tried the other way round by executing chroot using sde64 --
| Code: | | ./sde64 -icl -- /usr/bin/chroot /usr/x86_64-mypl-linux-gnu/ |
Here it sde64 executable exits and chroot just hangs. It has to be SIGKILLed.
I also tried to convert sde64 to static binaries and it did not help.
[Administrator note: this appears to follow from the qemu thread Determining unsupported instructions in qemu softmmu. -Hu]
_________________
My blog |
|
| Back to top |
|
 |
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
| Posted: Thu Mar 27, 2025 6:06 am Post subject: |
|
|
This 'Intel SDE' is propitiatory garbage.
| Code: | | E: Fork for injector launcher failed: Out of memory |
It can only be used for 'hello world' type programs.
_________________
My blog |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55096
Location: 56N 3W
|
| Posted: Mon Mar 31, 2025 8:30 am Post subject: |
|
|
dE_logics,
| Quote: | I tried the other way round by executing chroot using sde64 --
Code:
./sde64 -icl -- /usr/bin/chroot /usr/x86_64-mypl-linux-gnu/
Here it sde64 executable exits and chroot just hangs. It has to be SIGKILLed. |
The chroot leaves the sde64 dir outside of the chroot so that it can't load any more of itself.
It's Intel software, designed to emulate newer Intel CPU instructions, probably only on older Intel CPUs.
znver1 sounds a lot like AMD. I would not be surprised if it failed with AMD instructions involved either on the host or target.
I've not had an Intel CPU since my 32 bit Atom in an Acer One netbook, so I can't test here.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
| Posted: Mon Mar 31, 2025 10:25 am Post subject: |
|
|
But AMD is supposed to have extra instructions which Intel never incorporated. So that shouldn't be a problem. Also sde binary must be built with x86-64 baseline instruction set so it must run on even the 2003 era Athlon processors, but this zen. So it shouldn't be a problem.
So what I'll do is put the chroot dir in the sde64 dir (--bind mount).
_________________
My blog |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 748
|
| Posted: Mon Mar 31, 2025 11:17 am Post subject: |
|
|
| dE_logics wrote: | | but this zen. So it shouldn't be a problem. |
Zen has some "missing" instructions compared to Bulldozer, I'was bitten by it first 8 or so years ago during a "hardware upgrade", and avoided it recently again: Doing an emerge -e world on new hardware is always kinda cool, but having to do it before the hardware upgrade just sucks  |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
| Posted: Mon Mar 31, 2025 1:47 pm Post subject: |
|
|
| Ralphred wrote: | | dE_logics wrote: | | but this zen. So it shouldn't be a problem. |
Zen has some "missing" instructions compared to Bulldozer, I'was bitten by it first 8 or so years ago during a "hardware upgrade", and avoided it recently again: Doing an emerge -e world on new hardware is always kinda cool, but having to do it before the hardware upgrade just sucks |
But still there's no chance of Intel's SDE using those instructions. The machine I'm trying to chroot into us icelake.
_________________
My blog |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
| Posted: Mon Mar 31, 2025 1:49 pm Post subject: |
|
|
| dE_logics wrote: | But AMD is supposed to have extra instructions which Intel never incorporated. So that shouldn't be a problem. Also sde binary must be built with x86-64 baseline instruction set so it must run on even the 2003 era Athlon processors, but this zen. So it shouldn't be a problem.
So what I'll do is put the chroot dir in the sde64 dir (--bind mount). |
I put the chroot dir into the SDE's directory and still hanged.
Do you have any other suggessions. Would placing the sde dir's contents into the ROOT of the chroot dir help?
_________________
My blog |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 55096
Location: 56N 3W
|
| Posted: Mon Mar 31, 2025 7:18 pm Post subject: |
|
|
dE_logics,
The SDE must be available inside the chroot, or the chroot will leave the SDE outside the chroot and therefore inaccessible.
Putting SDE in your path, when you want to chroot is tricky as it will either be wrong inside or outside the chroot.
I'm surprised that you only pass ./SDE, a directory and not some binary program name within ./SDE, which effectively treats the program after the -- as data. Much as qemu does.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
| Posted: Tue Apr 01, 2025 12:29 pm Post subject: |
|
|
I'll try it out. But still a better approach will be to make the kernel execute the emulator when it detects that the executable lies in a certain matching path (like /tmp/portage). That way cross compiling bugs can be overcome and it'll still be reasonably fast.
I found update-binfmts --detector. This may work?
_________________
My blog |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2335
Location: $TERM
|
| Posted: Tue Apr 01, 2025 3:45 pm Post subject: |
|
|
| NeddySeagoon wrote: | dE_logics,
The SDE must be available inside the chroot, or the chroot will leave the SDE outside the chroot and therefore inaccessible.
Putting SDE in your path, when you want to chroot is tricky as it will either be wrong inside or outside the chroot.
I'm surprised that you only pass ./SDE, a directory and not some binary program name within ./SDE, which effectively treats the program after the -- as data. Much as qemu does. |
IT WORKED!! It to copy all SDE's 'innards' to / and also to /usr/x86_64-mypl-linux-gnu//usr/x86_64-mypl-linux-gnu/
Thanks for helping with all that experience Neddy!!
_________________
My blog |
|
| Back to top |
|
|
|
Kernel & Hardware
