This had fewer hiccups than I was expecting. Before I proceed to hammering VBoxManage into shape, does anyone see any problems with this approach?
These commands
execute amd64 binaries
using qemu-x86_64-static
in an amd64 chroot
in a mount of the Debian Bookworm amd64 Live ISO
in an arm64 Debian bookworm VM (the same one I used to built he raw Whonix images)
using VirtualBox 7.1.6
on macOS Sequoia
on an M1 Mac laptop
If this seems reasonable I will see if it can generate a working arm64 .vbox.
Iām kind of proud of this, particularly because it doesnāt require doing a Debian installā¦ this is A-level cross-platform VM shenanigans. Nice idea, Patrick!
# Set variables for readability
AMD64_ROOT='/home/builder/amd64'
BINDIR_PATH='/home/builder/derivative-binary/17.3.6.2'
AMD64_WORK_PATH='/tmp/amd64_work'
RAW_FILENAME='Whonix-Gateway-CLI-17.3.6.2.arm64.raw'
# Set derived variables for readability.
RAW_PATH="${BINDIR_PATH}/${RAW_FILENAME}"
AMD64_ISO_PATH="${AMD64_ROOT}_iso"
AMD64_RO_PATH="${AMD64_ROOT}_ro"
AMD64_RW_PATH="${AMD64_ROOT}_rw"
AMD64_MERGED_PATH="${AMD64_ROOT}_merged"
# Download required items
sudo apt-get install curl qemu-user-static
curl -L -O https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.10.0-amd64-standard.iso
# Set up AMD64 file system and required files
mkdir "${AMD64_ISO_PATH}" "${AMD64_RO_PATH}" "${AMD64_RW_PATH}" "${AMD64_MERGED_PATH}" "${AMD64_WORK_PATH}"
sudo mount -o loop debian-live-12.10.0-amd64-standard.iso "${AMD64_ISO_PATH}"
sudo mount -o loop "${AMD64_ISO_PATH}/live/filesystem.squashfs" "${AMD64_RO_PATH}"
sudo mount --bind /dev "${AMD64_RO_PATH}/dev"
sudo mount --bind /sys "${AMD64_RO_PATH}/sys"
sudo mount --bind /proc "${AMD64_RO_PATH}/proc"
mkdir -p "${AMD64_RW_PATH}${BINDIR_PATH}"
mv "${RAW_PATH}" "${AMD64_RW_PATH}${RAW_PATH}"
sudo mkdir "${AMD64_RW_PATH}/etc"
sudo cp /etc/resolv.conf "${AMD64_RW_PATH}/etc"
sudo mkdir -p "${AMD64_RW_PATH}/usr/bin"
sudo cp $(which qemu-x86_64-static) "${AMD64_RW_PATH}/usr/bin"
sudo mount -t overlay overlay -olowerdir="${AMD64_RO_PATH}",upperdir="${AMD64_RW_PATH}",workdir="${AMD64_WORK_PATH}" "${AMD64_MERGED_PATH}"
# Run something
sudo /sbin/chroot "${AMD64_MERGED_PATH}" qemu-x86_64-static /usr/bin/apt-get install hello
sudo /sbin/chroot "${AMD64_MERGED_PATH}" qemu-x86_64-static /usr/bin/hello
> Hello, world!
/usr/bin/dpkg --print-architecture
> arm64
sudo /sbin/chroot "${AMD64_MERGED_PATH}" qemu-x86_64-static /usr/bin/dpkg --print-architecture
> amd64
The good news is the problem exists in a vanilla Debian Bookworm VM in VirtualBox on an M1.
The bad news is Bookworm uses systemd 252.36-1~deb12u1 amd that is 3 major releases behind. Itās only 43 days out of date but they only accept bugs that are 1 or 2 major releases behind. So I canāt file a bug.
build-steps.d/1300_cowbuilder-setup is used to build chroots. Added some new code there just now.
if [ "$dist_build_virtualbox" = "true" ]; then
if [ "$dist_build_target_arch" = "arm64" ]; then
true "${cyan}INFO: '--target virtualbox' and '--arch arm64', therefore also building a AMD64 chroot, because at time of writing VirtualBox is available only on ARM64 macOS but not for ARM64 Linux.${reset}"
make_cross_build_platform_list_including_host_architecture+=" amd64 "
fi
fi
Butā¦
Installing VirtualBox inside that chroot using VirtualBox Installer for Linux (virtualbox-installer-cli (dist-installer-cli --virtualbox-only));
using that chroot to run build-steps.d/4600_create-vbox-vm inside it;
and combining this with SUDO_TO_VBOX_TEMP and/or HOMEVAR_VBOX_TEMP
@Patrick In the interest of not having to do it more than once and keeping it consistent with your vision, at what points in the code (file and section or line) do you imagine the three of these items happening?
Also, what is the digital-signatures-policy compliant way of installing VirtualBox Installer?
Noted. I suspect itās going to take me a little bit to get a reliably running system on M1. I will focus on getting that done and then I will look at some small bugs.
Iāve read the entire policy. Iām sure you donāt need my feedback but I appreciate you writing it up; it provides a good sense of what this project needs from (and can provide to) contributors.
FWIW, I do not see anything like a āgood first issueā tag as mentioned in Final Notes. I can dig around in the tracker on my own, though.
I have succeeded cross-building a Whonix VirtualBox ova image.
The build process succeeded without errors.
I havenāt attempted to actually import and boot the ova image on VirtualBox on a Mac M#. Booting it might actually fail. Needs testing.
Some hints for building:
Version 18 (and above) only.
Build host: Debian 13 / trixie or Kicksecure 18 on architecture Intel/AMD64.
Building on ARM64 isnāt be possible at the time of writing.
At the time of writing, VirtualBox provides Linux (Debian) packages for AMD64 only. ARM64 VirtualBox Linux packages arenāt available at the time of writing.
Building Whonix VirtualBox ARM64 on Debian / Kicksecure ARM64 will potentially become possible if running vboxmanage inside a chroot as discussed above.
Set target architecture to ARM64 usingderivative-maker command line option:
Iām trying to build whonix gateway virtualbox for use on a mac m3. Iāve followed the directions and it seems to finish building without error. But there is not any ova files produced, or at least I cannot find them. Iām using a x64 host running virtualbox and created a Debian trixie x64 vm. Once itās done building I see a folder called 18.1.4.2 and inside it is a single text file called Whonix-Gateway-LXQt-18.1.4.2.text. The full build command I used was
You have to build both the gateway and the workstation to get an OVA file. Run the exact command you show above, but change --flavor whonix-gateway-lxqt to --flavor whonix-workstation-lxqt; this will build the Workstation, and will then package both the gateway and workstation together into the OVA file.
I donāt think there is currently a supported way to build an OVA with just the gateway, although you could probably use the raw disk image generated during the Whonix-Gateway build all by itself with some effort.
After building both, the build script do indeed build a unified ova file. However, when I copy it to my mac and import it. The VMās fail to start saying:
Cannot run the machine because its platform architecture x86 is not supported on ARM.
Result Code:
VBOX_E_PLATFORM_ARCH_NOT_SUPPORTED (0x80bb0012)
Component:
MachineWrap
Umā¦ ok well thatās weird. I wonder if the built image has some architecture indicator inside that makes it claim to be x86_64, when in reality itās arm64? OVA files are just renamed tarballs, and IIRC there should be a manifest in there with some metadata about the VM images. Can you look at that and see?
Iāve since discovered that about ova files. It did contain some stuff about x64(like OsType) and even after changing it to arm64 it still doesnāt boot. Iāve exhausted my know how on this type of stuff and I guess Whonix is just not ready for me to use.
The Apple Silicon support isnāt well-maintained at the moment, it is worked on but isnāt perfect. You might have better luck building qcow2 images to use with UTM.