Well no. We are underfunded and understaffed and are not concentrating on supporting physical workstations which need much more effort then we can afford. Thats to say nothing of how the state of ARM hardware support remains a clusterfuck thanks to non standard booting, non mainlined GPU drivers and every hardware vendor doing their thing. Its more like a bunch of silos or feudal prisons.
2 Likes
I would like to contribute! I have raspberry pi 3 b for testing and enthusiasm to make it possible. I have the following skills: shell, git, python. But I need a direction - where to start. Could anyone of maintainers please direct me… Like telling what would be great to be done first etc. I would love to help!
2 Likes
There might not be too much to do to make it work. Whonix’s doesn’t to platform specific stuff.
These skills are sufficient.
Confirm rasbberry pi 3 b works with Debian?
For now, just try to build a Whonix-Gateway version 14.
As an exercise, build Whonix 14 for VirtualBox first to learn the “normal” process and iron out any non-arm related build issues.
- Build and Update Whonix ™ from Source Code
- https://www.whonix.org/wiki/Dev/Build_Documentation/14_full
Then use a s slight variation of the build command to build a raw image.
--target raw
Adjust arch. Try.
--arch arm64
Also…
--kernel linux-image-arm64--headers linux-headers-arm64
Is it arm64? Otherwise adjust as per a supported platform by Debian. arm64, armel or armhf?
sudo REPO_PROXY=http://127.0.0.1:3142 ~/Whonix/whonix_build --flavor whonix-gateway --target raw --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64
See if that builds? Fix whatever needed. Flash the image, try to boot. Works?
More details can be discussed later.
Thank you very much for guidance.
Currently running minibian (minimal Raspbian, which is Debian for rpi).
The architecture is shown as armv7l:
$ uname -m
armv7l
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
...
Can I assume that everything in your comment with arm64 must be changed to armv7l?
Btw, FreeBSD (raspBSD) on the same Rpi3 shows architecture as arm64 and works fine.
drew:
Can I assume that everything in your comment with
arm64must be changed toarmv7l?
I have no idea. Try.
Raspbian is not debian. Either you use raspbian as base to build or debian arm64. I’d recommend debian since Whonix is based on that and you will have a higher chance that the build will be successful. If you make the build based on raspbian it could also work and you could use the image on multiple rpi versions. In this case you also have to change the sources in the build script to the raspbian mirror. You probably want to cross build on a fast desktop machine instead of the rpi otherwise the build could easily take several hours.
3 Likes
a Project to look at and might help getting ideas from:
I wonder where they got that name from?
https://whonix.org/wiki/History
https://trac.torproject.org/projects/tor/wiki/doc/TorBOX?version=1
TorBox seems to be common name , there is as well TorBox as an email provider:
I am thinking about working on arm64 support and testing the results on qemu-arm.
What files do I need to change or look at when doing this?
Is it as simple as adding the extra arch parameters in this file?
https://github.com/Whonix/Whonix/blob/master/buildconfig.d/30_target_arch.conf
You’ve added all architectures to the repo source lists so could it be simple as specifying one of them for debootsrap to download?
HulaHoop:
I am thinking about working on arm64 support and testing the results on qemu-arm.
Cool.
What files do I need to change or look at when doing this?
Is it as simple as adding the extra arch parameters in this file?
Don’t edit files in .d folders generally. Add your own. See Whonix
source code introduction. You can also use …/buildconfig.d to get away
from any conflicts.
But in this case you don’t even need that. --arch amd64 or similar is
enough.
You’ve added all architectures to the repo source lists so could it be simple as specifying one of them for debootsrap to download?
TBB isn’t available for anything but i386 and amd64 from TPO. Otherwise
maybe not much missing. Try.
Not relevant at the moment until I finish testing x86-64. Does the requirements for build machine kernel architecture apply here too? How would the instructions posted in your comment affect what I am trying to do here?
I don’t know that. Try.
Possible that you need to be running arm64 kernel. Or even arm64
architecture. Try.
For the build command, will certainly need both, --arch and --kernel.
Try this.
The other build seems to be churning along without problems and is pulling packages from stretch. At the moment the build script would not be able to support building images with a kernel archtiecture different from what the build machine is running so its certain this won’t work.
However debootstrap can do this if the build script supports passing the “–foreign” option.
The options available for crossbuilding:
Example of Debootsrap’s foreign option:
https://wiki.debian.org/EmDebian/CrossDebootstrap#Generating_cross_images_as_root_user
HulaHoop:
At the moment the build script would not be able to support building images with a kernel archtiecture different from what the build machine is running so its certain this won’t work.
The build script is a lot less magic than you think. Grep the code for i386, i686 and amd64. There is nothing that makes it platform specific In essence, it combines Debian packages in commands in useful ways. Everything script does could also be done manually. So there is no inherent limitation. If there is a limitation, it would be one of for example [grml-]debootstrap. Not one of the build script.
However debootstrap can do this if the build script supports passing the “–foreign” option.
The options available for crossbuilding:
EmDebian/CrossDebootstrap - Debian Wiki
Example of Debootsrap’s foreign option:
https://github.com/Whonix/Whonix/blob/master/build-steps.d/1300_create-raw-image is of interest here. It runs grml-debootstrap, which internally uses debootstrap. So during 1300_create-raw-image runs, the command invocation line of grml-debootstrap is of interest here.
[grml-deboostrap is a tool that can create Debian raw images.
debootstrap is a tool that can install Debian into folders.]
So in summary, if grml-deboostrap can do, then Whonix’s build script can
also.
grml-deboostrap supports…
--debopt params
Extra parameters passed to the debootstrap command.
You can inject what’s being passed to grml-debootstrap --debopt through the following variable. Example.
whonix_build_debopt+=" --verbose "
Great it makes the script extensible.
Besides --foreign the paramter --second-stage-target=DIR is needed but what DIR should DIR take?
Can’t you just leave the defaults?
In case you don’t know, you are not supposed to create the full line for
invocation of debootstrap. grml-debootstrap passes most parameters just
fine. Search the build log for debootstrap. You only need to add any
extra arguments for cross platform building.
–foreign is required for crossbuilding and --second-stage-target= for debootstrap to be able to successfully build on non native hardware past stage 2 and as non root.
I’m thinking when doing crossbuilds a new folder with the intended arch name should be created. I don’t know if that directory should be in the Whonix source one or created outside.
~/whonix_binary folder somewhere.
Please make it work with deboostrap first. Then make it work with
grml-debootstrap. From there it will be simple to make it work with Whonix.
Seems that an actual ARM device would be needed for debootstrap’s second stage to succeed:
http://forums.debian.net/viewtopic.php?t=44617
The best option would be to just support a normal build script with --arch on an emulated Debian qemu-arm environment.
EDIT:
After trying that I ran into several problems mainly the extreme slowness of emulation and lack of a video device support.
The only practical way is to generate an image on an arm64 hardware when available with minimal changes to the build script by adding --arch arm64. Crossbuilding won’t be a problem then.