Another way is to use
LD_LIBRARY_PATH - but that doesn't work (at least for me) for the later-loaded libraries, like
libnss_dns and so on.
Even using the
rpath parameter for linking doesn't quite work - all dynamically loaded things, like locale data, timezones, message tables, and so on are taken from the current root on - and may not match the needed versions.
This works by calling this wrapper program; it goes into a
chroot jail and calls FSVS with additional data; FSVS then tries to load all needed libraries (see hlp__chrooter), and goes out of the jail to resume operations from the default enviroment.
./configure --with-chroot=/usr/local/fsvs-chroot make
This builds only
tools/fsvs-chrooter -- this you put into
whereever you like. It should be in a directory listed in
Don't forget to copy the later-loaded libraries and data files -
ldd fsvs won't give you the whole list! You can get a good list to start (on the current machine) with
strace -e open -o /tmp/list fsvs remote-status
Please create the whole structure (as far as needed) as it is - ie.
/usr/local/fsvs-chroot/ lib/ libc.so.6 ld-linux.so.2 ... usr/ lib/ libnss_dns.so ... local/ bin/ fsvs
Why? First, it's easier for you to update later, and second the dynamic linker knows where to look.
straceoutput - such things as
/etc/nsswitch.conf and so on. These tell the network libraries how to resolve names via DNS, and similar data.
A binding mount would be better still - but as
/etc/ld.so.cache should be taken from the newer machine, you'd have to do every single file.
It should be possible to simply have no
ld.so.cache file; then the dynamic linker would have to search the directories by himself.
Although it might be better to set the environment variables for
fsvs-chrooter in a shell script named FSVS - then the other programs won't have to put up with the long library list.
The prepare script below generates such a file.
tools/, you'll find a script named
prepare-chroot.pl. This is what I use to create the
chrootjail on my debian unstable machine.
/to set the correct root directory back; and the current working directory has to be restored, too.
chroot(current working directory), we'd see a completly different directory structure than all the other filesystem tools (except for the case
cwd = "/", of course).
Maybe give the chrooter setuid and drop priviledges after returning from chroot() jail? Not sure about security implications, seems to be unsafe. Does anybody know how to do that in a safe manner?
If your old system is a really old system, with a kernel before 2.4.17 or something like that, you might get problems with the threading libraries -
LD_ASSUME_KERNEL to read a bit about the implications.
Information about how to proceed there is wanted.
stracetrick. Patches are welcome!
Ideas, suggestions, feedback please to the mailing lists.