Difference between revisions of "Package:Fchroot"

From Funtoo
Jump to navigation Jump to search
m (add qemu targets to portage =D)
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
"fchroot" is the Funtoo franken-chroot tool, which uses the power of QEMU to allow you to "fchroot" into a non-x86 system on an x86 system and use it as if it were a native chroot.
It currently allows chrooting into arm-32bit, arm-64bit and riscv-64bit systems on a regular 64-bit PC.
The pypi package index for fchroot can be found here: https://pypi.org/project/fchroot/
=== Installation ===
To emerge fchroot, perform the following steps:
{{console|body=
{{console|body=
###i##  
###i## cat >> /etc/portage/package.use << "EOF"
echo 'QEMU_USER_TARGETS="aarch64 arm"' >> /etc/portage/make.conf
app-emulation/qemu static-user qemu_user_targets_aarch64 qemu_user_targets_riscv64 qemu_user_targets_arm
echo "app-emulation/qemu static-user qemu_user_targets_aarch64 qemu_user_targets_riscv64 qemu_user_targets_arm" >> /etc/portage/package.use
dev-libs/glib static-libs
echo "dev-libs/glib static-libs" >> /etc/portage/package.use
dev-libs/libpcre static-libs
echo "dev-libs/libpcre static-libs" >> /etc/portage/package.use
sys-apps/attr static-libs
echo "sys-apps/attr static-libs" >> /etc/portage/package.use
EOF
emerge -av fchroot
###i## emerge -av fchroot
}}
}}
=== Use ===
You can now extract your non-x86 stage3 tarball to your preferred location, such as {{c|/var/tmp/riscv-stage3}}, and then fchroot into it:
{{console|body=
# ##i##cd /var/tmp/riscv-stage3
# ##i##tar --numeric-owner --xattrs --xattrs-include='*' -xpf stage3-sifive-fu740-next-2021-10-21.tar.xz
# ##i##fchroot . /bin/bash
>>> Setting up /proc...
>>> Setting up /sys...
>>> Setting up /dev...
>>> ##y##riscv-64bit##!y## frankenchroot B]...
%fchroot%
}}
Fchroot does the steps necessary to enable the QEMU emulation, and also takes care of performing bind-mounts for {{c|/dev}}, {{c|/proc}} and {{c|/sys}}, and copying {{c|/etc/resolv.conf}} into the chroot environment to ensure that name resolution works.
You are now fchrooted into a riscv environment, running riscv via QEMU, and this will be reflected in the {{c|uname -a}} output:
{{console|body=
%fchroot% ##i##uname -a
Linux ryzen 5.10.46_p4-debian-sources #1 SMP Wed Aug 4 23:05:15 MDT 2021 ##g##riscv64##!g## GNU/Linux                                                                       
}}
You can do anything you would do in a regular chroot, including {{c|ego sync}} and emerging things, as long as you disable {{c|pid-sandbox}}
for Portage:
{{file|name=/etc/make.conf |desc=add sandbox|body=
FEATURES="-pid-sandbox"
}}
=== Implications ===
In your fchrooted environment, you will be running a 'native' RISCV or ARM system, but it will be executing via QEMU transparently whenever it encounters a binary that is for the foreign architecture. It will have the number of cores and the amount of memory that you have on your host x86 system. When you use 'htop' in the chroot, you will be able to see all processes on your x86 system. If you run 'htop' outside of the fchroot, you will be able to also see processes running inside the fchroot. You will also see that all executables running in the fchroot are using a QEMU wrapper to execute. This is done transparently by the kernel after fchroot has done its configuration magic.
It's even possible to fchroot into an NFS mount of a remote RISCV or ARM system, and compile packages using your x86 CPU and memory. The packages that install will be for the native architecture. This is very handy for raspberry pi and systems that have minimal RAM and cores.
See a live demo here:
{{#evt:service=youtube|id=https://youtu.be/TAg2mfwPtHY}}
[[Category:First Steps]]

Revision as of 02:23, October 23, 2021

"fchroot" is the Funtoo franken-chroot tool, which uses the power of QEMU to allow you to "fchroot" into a non-x86 system on an x86 system and use it as if it were a native chroot. It currently allows chrooting into arm-32bit, arm-64bit and riscv-64bit systems on a regular 64-bit PC.

The pypi package index for fchroot can be found here: https://pypi.org/project/fchroot/

Installation

To emerge fchroot, perform the following steps:

root # cat >> /etc/portage/package.use << "EOF"
app-emulation/qemu static-user qemu_user_targets_aarch64 qemu_user_targets_riscv64 qemu_user_targets_arm
dev-libs/glib static-libs
dev-libs/libpcre static-libs
sys-apps/attr static-libs
EOF
root # emerge -av fchroot

Use

You can now extract your non-x86 stage3 tarball to your preferred location, such as /var/tmp/riscv-stage3, and then fchroot into it:

root # cd /var/tmp/riscv-stage3
root # tar --numeric-owner --xattrs --xattrs-include='*' -xpf stage3-sifive-fu740-next-2021-10-21.tar.xz
root # fchroot . /bin/bash
>>> Setting up /proc...
>>> Setting up /sys...
>>> Setting up /dev...
>>> riscv-64bit frankenchroot B]...
fchroot #

Fchroot does the steps necessary to enable the QEMU emulation, and also takes care of performing bind-mounts for /dev, /proc and /sys, and copying /etc/resolv.conf into the chroot environment to ensure that name resolution works.

You are now fchrooted into a riscv environment, running riscv via QEMU, and this will be reflected in the uname -a output:

fchroot # uname -a
Linux ryzen 5.10.46_p4-debian-sources #1 SMP Wed Aug 4 23:05:15 MDT 2021 riscv64 GNU/Linux

You can do anything you would do in a regular chroot, including ego sync and emerging things, as long as you disable pid-sandbox for Portage:

   /etc/make.conf - add sandbox
FEATURES="-pid-sandbox"

Implications

In your fchrooted environment, you will be running a 'native' RISCV or ARM system, but it will be executing via QEMU transparently whenever it encounters a binary that is for the foreign architecture. It will have the number of cores and the amount of memory that you have on your host x86 system. When you use 'htop' in the chroot, you will be able to see all processes on your x86 system. If you run 'htop' outside of the fchroot, you will be able to also see processes running inside the fchroot. You will also see that all executables running in the fchroot are using a QEMU wrapper to execute. This is done transparently by the kernel after fchroot has done its configuration magic.

It's even possible to fchroot into an NFS mount of a remote RISCV or ARM system, and compile packages using your x86 CPU and memory. The packages that install will be for the native architecture. This is very handy for raspberry pi and systems that have minimal RAM and cores.

See a live demo here: