repen 650234
quit
I guess I'm wondering whether I should be letting #650234 close and we
need a separate bug for the current phase... The provided explanation
of the status does not make sense. The explanation I can come up with is
the wrapping is working, except around shell scripts. For
On Wed, Nov 27, 2013 at 10:15:19PM +0100, Piotr Roszatycki wrote:
2012/10/24 Jonathan Nieder jrnie...@gmail.com:
Thanks. Indeed, ideally fakechroot's execve should look up the
interpreter filename from the ELF .interp section, map it according to
the faked chroot, and set argv[0]. The
2012/10/24 Jonathan Nieder jrnie...@gmail.com:
Thanks. Indeed, ideally fakechroot's execve should look up the
interpreter filename from the ELF .interp section, map it according to
the faked chroot, and set argv[0]. The hard part is the ELF parsing.
It doesn't work correctly:
1. The glibc
unmerge 626482
reassign 650234 fakechroot 2.15-1
severity 650234 important
tags 650234 + upstream
quit
Elliott Mitchell wrote:
user@host:/$ ls
Segmentation fault
user@host:/$ /lib/ld-linux.so.2 ls
ls: error while loading shared libraries: ls: cannot open shared object file:
No such file or
found 2.9-1.1+squeeze1
found 2.16-1
quit
This appears to be an issue for a lot more than just 2.15-1. I could be
wrong, but I'd assume it is in pretty well every version.
--
(\___(\___(\__ --= 8-) EHM =-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP
Any progress as solving #650234? Reads like the problem has been
identified, but no solution has come up. I've got no idea if any
possible solutions are visible...
One thought, in wrapping execve(), use chroot/lib/ld-linux.so.2 as
the filename. Push chroot/lib/ld-linux.so.2 on to argv[], then
Simple test I tried in a test chroot image area:
user@host:~/build$ fakechroot
user@host:~/build$ chroot test.image
Segmentation fault
user@host:~/build$ chroot test.image /lib/ld-linux.so.2 /bin/bash
user@host:/$ ls
Segmentation fault
user@host:/$ /lib/ld-linux.so.2 ls
ls: error while loading
7 matches
Mail list logo
