This question, Figuring out what OS is on which partition?, got me into thinking if you could run the executables from a mounted distro without actually having booted into said distro.The answer to this question, How to recover from a chmod -R 000 /bin?, got me into thinking that perhaps you could call the loader from the mounted distro's partition.Is this possible? ExampleWhen I tried it, it didn't work, but I'm thinking I might be missing some other bits.The command I was trying this with was lsb_release. I'm on a 64-bit Fedora 14 installation at the moment, if that matters.$ sudo /lib/ld-2.13.so /usr/bin/lsb_release/usr/bin/lsb_release: error while loading shared libraries: /usr/bin/lsb_release: invalid ELF header
Can executables from a mounted distro's disk be run without booting into it?
dual boot;executable
Yes, provided that the running kernel is capable of running the binaries from the mounted distribution.This requires that the mounted distribution is for the running processor architecture, or a compatible one. You aren't going to be able to run ARM binaries on an x86 processor, for example. Compatibility depends on the CPU; for example, on x86/amd64, 64-bit binaries run only on 64-bit CPUs while 32-bit binaries run on both 32-bit and 64-bit CPUs. Compatibility also depends on the operating system; for example, on x86_64 CPUs, Solaris can run indifferently 64-bit and 32-bit programs on 32-bit and 64-bit kernels; Linux 64-bit kernels can run 32-bit programs but not vice versa; while OpenBSD 64-bit kernels cannot run 32-bit programs.Statically-linked executables will run in place with no effort, provided that they aren't looking for files in fixed locations. Dynamically-linked executables may not work if the mounted distribution has a more recent version of the C library, or is using a different C library (e.g. uClibc vs. Glibc), or is using a different architecture for which the host has no userland support (e.g. i386 vs amd64, armhf vs armel).Sometimes, to make dynamically-linked executables work, you'll need to both call the dynamic linker explicitly, and put the library directories of the mounted system first on the library search path.LD_LIBRARY_PATH=/mnt/lib:/mnt/usr/lib /mnt/lib/ld-linux.so.2 /mnt/bin/fooAn easy way to be sure that the program from the mounted system will find everything it needs in the right place (loader, libraries, configuration files, data files, etc.) is to run it in a chroot. A chroot restricts the view of the filesystem to a single directory and its subdirectories. Only root can call the chroot command.chroot /mnt /bin/fooSince the program is running with /mnt as its root directory, it won't see anything outside that hierarchy: no /home (or rather, the one from /mnt), no /proc, only the static default for /dev, etc. The special filesystems such as /proc can be mounted in the chroot, from the outside (mount -t proc proc /mnt/proc) or from the inside (mount -t proc proc /proc). Under Linux, directories can be re-mounted in a second location (while remaining wherever they were already) with mount --bind, or with mount --rbind to also replicate filesystems mounted underneath the specified directory.mount --rbind /dev /mnt/devmount --bind /home /mnt/homemount --bind /proc /mnt/procmount --bind /sys /mnt/syschroot /mnt /bin/fooDebian and some other distributions provide a tool called schroot to automate such mounts and perform other niceties. It's overkill for a one-off thing, but convenient if you want to maintain multiple distributions.