Skip to main content

You can most definitely 'chroot' into a (mounted) filesystem meant for a different architecture and do some meaningful work, you just need the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: http://proot.me/https://proot-me.github.io/

Together with QEMU's user mode emulators, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

You can most definitely 'chroot' into a (mounted) filesystem meant for a different architecture and do some meaningful work, you just need the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: http://proot.me/

Together with QEMU's user mode emulators, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

You can most definitely 'chroot' into a (mounted) filesystem meant for a different architecture and do some meaningful work, you just need the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: https://proot-me.github.io/

Together with QEMU's user mode emulators, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

added 4 characters in body
Source Link
ack
  • 1.1k
  • 1
  • 10
  • 6

You can most definitely chroot'chroot' into a (mounted) filesystem meant for a different architecture and do some meaningful work, if you havejust need the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: http://proot.me/

Together with QEMU's user mode emulationemulators, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

You can most definitely chroot into a (mounted) filesystem meant for a different architecture and do some meaningful work, if you have the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: http://proot.me/

Together with QEMU's user mode emulation, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

You can most definitely 'chroot' into a (mounted) filesystem meant for a different architecture and do some meaningful work, you just need the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: http://proot.me/

Together with QEMU's user mode emulators, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.

Source Link
ack
  • 1.1k
  • 1
  • 10
  • 6

You can most definitely chroot into a (mounted) filesystem meant for a different architecture and do some meaningful work, if you have the right tools.

Have a look at PRoot, which is a user-space implementation of chroot, mount --bind, and binfmt_misc: http://proot.me/

Together with QEMU's user mode emulation, you're all set.

Although you usually cannot perform a 'full' boot (i.e. starting init and services), it is good enough to run some binaries from their 'natural' place, with access to all their configuration files, including some that are bind-mounted from the 'host' system, etc.