grml-debootstrap or package compiling is easy when doing same architecture builds but crossbuilds and crosscompiling are where things get complicated.
Cross builds are missing features in grml-debootstrap or
image-bootstrap. Post feature requests against both projects. Or add
these features to these projects. We cannot [also no need] invent this here.
The qemu-debootstrap wrapper calls debootstrap(8) making use of the --foreign and --second-stage options, and copies the appropriate qemu-user-static(1) binary into place in order to install cross-architecture chroots. In order for it to work seamlessly, the binfmt-support package must be installed.
for i in prepare_vm mkfs tunefs mount_target debootstrap_system preparechroot execute_pre_scripts chrootscript execute_scripts umount_chroot finalize_vm fscktool
I just want to drop in to tell you both that I GREATLY appreciate this effort. Hopefully a useable build can come to fruition.
At the present moment, is it possible to at least use qemu to build a working Whonix Gateway containing some binary blobs / precompiled headers etc? I may be willing to run a mostly-transparent build if this is the case. What is the status in this regard?
Just the project I was looking for: Armbian is a cross-compiling toolchain project that runs on x86 hardware and generates Debian images for ARM boards:
The hypervisor is just a recommended dependency to create a self contained build environment. It also assumes that people could be running non Linux hosts that cannot run the toolchain.
Resurrecting this old thread …
I gave it a try and running the scripts in build-steps.d/ with some minor modifications + some rpi firmware stuff gave a bootable image for the rpi 3 which connected to the tor network.
A problem is in the 1300 script with grml-debootstrap. It will always try to install grub-pc and fail since the package is not available for arm64. Is it somehow possible to disable the whonix build script error handler for this specific error or to just automatically continue? Cross debootstrapping works otherwise.
Running the image is still sort of slow/buggy, maybe because of kde/gui or other reasons.
Is there some kind of list of essential packages for a non-gui gateway?
Running 1300 alone takes 1:15 h which I’d like to cut down.
Seems like a bug or missing feature in grml-debootstrap. Feel free to work on that with upstream so we could make it easier to not hardcode that file / content in Whonix for easy arm support without need to modify a file beforehand.
grml_packages should already be as minimal as possible without confusing grml-debootstrap. By removing grub-pc without replacement the image may or may not boot. Perhaps there is a package tailored for arm? See list: Debian -- Details of source package grub2 in buster
There is variable last_failed_bash_command in https://github.com/Whonix/Whonix/blob/master/help-steps/pre. In function errorhandlerprocessshared we could check a to be introduced variable with a whitelist of commands (maybe just the first word of the variable) which are ignored to fail or something like that.
But that may not work for this specific case since this error is deep inside grml-debootstrap which is from Whonix build script perspective just a single command.
I am not satisfied with https://github.com/Whonix/Whonix/blob/master/build-steps.d/1700_install-packages. I would like to get rid of the -pre packages. Maybe that workaround is no longer required anyhow. Maybe Whonix’s build script should be ported from chroot to systemd-nspawn anyhow which may allow to get rid of the -pre packages.
But while 1700_install-packages has a feature “skip to install this package” there is a missing feature “do install this package”.
So for a quick test just try to hardcode it by replacing pkg-install-maybe non-qubes-whonix-gateway with pkg-install-maybe whonix-gateway-packages-dependencies
Removing grub-pc from grml-packages won’t help since installing the package is hardcoded in /usr/sbin/grml-debootstrap. It will always be installed when building a VM image. A workaround might be to install in a directory and create the image afterwards so the following build scripts would still work. the rpi needs some other filesystem layout anyways. I’d probably create a new flavor like whonix-gateway-rpi which only creates a minimal system + maybe packages for wifi support. Another issue is the lacking rtc so timesync will always fail and I had to set the date manually. I’m also not sure what to do with eth0. Currently the IP is hardcoded and won’t be of any use. Either use dhcp or leave the network configuration to the user.
Is there maybe some way in the 1200 step to only build packages required for the specific flavor?