Closed dleonard0 closed 1 year ago
Wow, that’s very interesting. I’m curious about how the proposed flag will work. Is this only for environments with glibc and musl on the same system?
Wow, that’s very interesting. I’m curious about how the proposed flag will work.
My attempt currently uses an option to disable a single block in expand_runner()
; see https://github.com/proot-me/proot/compare/master...dleonard0:proot:no-host-elf
Is this only for environments with glibc and musl on the same system?
That would be my case, but it is more general than that. My case is building a sysroot for an embedded target and wanting to run some small unit tests during build. I suppose what I have is a case where proot's current mixed execution assumption isn't right for me, though I can understand why it is the default.
Update: fixed logic bug, in my attempt; updated URL above
My only regret here here my use of the double-negative form !no_host_elf
and that host-elf is not very user-friendly ... I would be happy to receive direction to improve that... maybe naming it --no-mixed-mode
or something?
My only regret here here my use of the double-negative form
!no_host_elf
and that host-elf is not very user-friendly ... I would be happy to receive direction to improve that... maybe naming it--no-mixed-mode
or something?
How about --mix-mode=false
? What if we make it a boolean?
@dleonard0 please test the latest changes on my new branch. I changed the flag to accept a boolean value but it keeps crashing when I run it:
proot --mixed-mode true -v 1
proot info: binding = /
proot info: exe = /bin/sh
proot info: argv =
proot info: initial cwd = /usr/src/proot
proot info: verbose level = 1
proot info: pid 2491: access to "/dev/pts/0" (fd 0) won't be translated until closed
proot info: pid 2491: access to "/dev/pts/0" (fd 1) won't be translated until closed
proot info: pid 2491: access to "/dev/pts/0" (fd 2) won't be translated until closed
proot info: pid 2491: access to "/proc/2491/fd" (fd 3) won't be translated until closed
proot info: ptrace acceleration (seccomp mode 2) enabled
proot error: execve("/bin/sh"): Bad address
proot info: possible causes:
* the program is a script but its interpreter (eg. /bin/sh) was not found;
* the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
* the program is a foreign binary but qemu was not specified;
* qemu does not work correctly (if specified);
* the loader was not found or doesn't work.
fatal error: see `proot --help`.
proot info: vpid 1: exited with status 1
proot --mixed-mode false -v 1
proot info: binding = /
proot info: exe = /bin/sh
proot info: argv =
proot info: initial cwd = /usr/src/proot
proot info: verbose level = 1
proot info: pid 2493: access to "/dev/pts/0" (fd 0) won't be translated until closed
proot info: pid 2493: access to "/dev/pts/0" (fd 1) won't be translated until closed
proot info: pid 2493: access to "/dev/pts/0" (fd 2) won't be translated until closed
proot info: pid 2493: access to "/proc/2493/fd" (fd 3) won't be translated until closed
proot info: ptrace acceleration (seccomp mode 2) enabled
proot error: execve("/bin/sh"): Bad address
proot info: possible causes:
* the program is a script but its interpreter (eg. /bin/sh) was not found;
* the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
* the program is a foreign binary but qemu was not specified;
* qemu does not work correctly (if specified);
* the loader was not found or doesn't work.
fatal error: see `proot --help`.
proot info: vpid 1: exited with status 1
Expected Behavior
Actual Behavior
The issue (I think) is that romfs/bin/sh appears to proot to be a native ELF executable, so it enters mixed-execution mode using preserved native LD_LIBRARY_PATH. The trouble is that my romfs/bin/sh was built using a different ld.so and libc (musl), so the elf interp won't be found. I'd also like to run it under the (potentially modified) QEMU that i've specified.
I'm working on adding a
--no-host-elf
flag to see if that helps.Specifications
Log
(replaced workdir with "D")