[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Whonix for arm64 / Raspberry Pi ( RPi )

arm64
raspberry-pi_rpi

#101

Algernon:

Some people recently claimed in some benchmarking thread on the linux reddit that KDE now consumes less resources. Afaik even less than XFCE. Same happened back then on github qubes-issues when qubes introduced XFCE. So it would be maybe a good idea to do some benchmarking first, in particular for stuff from buster which is not that far away and would be the likeliest target for a new desktop environment.

I haven’t found any mentions of this. Please provide.

What I did read though was that XFCE works better in low RAM
environments. KDE might be even faster than that but requires more RAM
for that. Since RAM is limited in Whonix, this would still point at
XFCE. Also KDE might have better rendering speed on real hardware, but
that again wouldn’t effect Whonix in VMs much.

It was horrible to change from Whonix-Gateway from 512 MB RAM -> 768 MB
RAM; and Whonix-Workstation from 768 MB RAM to 1024 MB RAM.


#102


Though you might want to look in the comments because some say the measurements were flawed.


#103

What’s next?

Should Whonix for arm64 / Raspberry Pi ( RPi ) be documented, announced as Whonix news, call for testers or something?


#104

I’m fairly sure I submitted documentation for building and the general setup to the wiki. iirc to the physical isolation page but I can’t find it. Is there maybe some log with submitted content?


#105

https://www.whonix.org/wiki/Special:RecentChanges


#106

Are those the real changes or also the submissions? Afaik my changes still had to be approved by one of the wiki mods.


#107

All changes are there. Approved or not. Even non-approved changes stay in the log unless explicitly deleted (didn’t happen).


#108

https://www.whonix.org/wiki/Special:UnreviewedPages (just a subset of https://www.whonix.org/wiki/Special:RecentChanges).

btw: https://www.whonix.org/wiki/Special:SpecialPages


#109

I see, so I guess I have to add it again. I can’t access https://www.whonix.org/wiki/Special:UnreviewedPages due to lacking permissions.


#110

Thanks for submitting the documentation!

https://www.whonix.org/wiki/Dev/Build_Documentation/Physical_Isolation#How_To_Install_Whonix-Gateway_on_the_Raspberry_Pi_3_B_.28RPI3.29

When using ( ) in titles it makes the resulting link look ugly (part .28RPI3.29).

Should we update https://www.whonix.org/wiki/Dev/Build_Documentation/Physical_Isolation#Security_and_Support_Status?

Should we update https://www.whonix.org/wiki/Download - (https://www.whonix.org/wiki/Template:Supported_Platforms_Table)?


Long Wiki Edits Thread
#111

I can test the images from time to time. If it will be added to official downloads list I’d still add the “Advanced” and “Experimental” tag.
Also there would be easier ways for physical isolation on other system than the rpi i.e. by using the raw images and just burning those to disk as already described somewhere in this forum instead of going through a default debian installation + build from source.
I don’t know if it would be feasible to upload compressed raw images? They should work on most systems, however, there could be issues with ethernet or graphics drivers and uefi.


#112

Yes. I saw Netrunner for Odroid C1+ coming with a script to automatically resize the disk image at first boot.

Most likely yes.

We already have code to compress qcow2. https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/prepare_release#L34
Perhaps same/similar code would also work to compress raw images.

Added.

Open to more changes throughout the website.


#113

imho it would also be a good idea to reduce the default image sizes to maybe 8-16 GB or to make dedicated raw images for physical isolation of this size. Otherwise you will always have to burn a 100GB image which takes a while. Also physical isolation is an edge case and I’m not sure if anyone ever reaches the 100GB limit even on a virtual gateway. With a smaller size it can fit on the average USB or SSD, you can always resize the disk image if you need more space. I can try to add a script for such an image to the build steps.


#114

Not for VirtualBox builds please because there it’s quite handy. VMs won’t use that much space but can grow until that amount of space. (Sparse images.)

For --target raw (we already have that), other defaults less than 100 GB are fine. (--target raw isn’t really used by anyone yet afaik.)

For --target root, other defaults less than 100 GB are fine as well.


#115

#116

Was merged.

Do we still require our grml-debootstrap fork?


#117

I’d like to get rid of our grml-debootstrap fork (or at very least close the delta with upstream) since they recently merged to enhancements.


#118

How is this different from zerofree?

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2350_zerofree-raw

Do we need both?

Can or should both steps be merged?

Can 2550_shrink_raw use the same method to mount the raw image like 2350_zerofree-raw?

Is truncate --size=3500M "$binary_image_raw" required or does --vmsize 4G do the same? (Perhaps even vmsize 3500M already works?)

Could you please move the raw image compression to prepare_release? Reason:
Those who create the raw image for themselves only, don’t require compression?
Those who wish to redistribute images should prepare_release.

Could you make the raw compression code please similar to https://github.com/Whonix/whonix-developer-meta-files/blob/master/release/prepare_release#L70 so it will be deterministic?


#119

Zerofree overwrites free parts with zeros for better compression later on.
The 2550_shrink_raw script, however, shrinks the whole disk including the partition.
They could maybe be merged but then you have to create a raw backup image. The 2550_shrink_raw script currently does that though it is not strictly required. After merge you need to shrink and truncate the one of the images while converting the other image to qcow2 and vdi. Otherwise you would get a default disk size of ~ 4GB for the gateway VM.
2550_shrink_raw does not mount the disk.

If you would do a completely separate build of the images for physical isolation then this would certainly be an alternative. Result should be the same. I’m going to give it a try. With the 2550_shrink_raw script + the --phys switch you could build the images for physical isolation + the VM images in one step.

Yes.

Yes.


#120

Another non-perfection not easy to perfect.

non-qubes-whonix-(gateway|workstation)-(cli|kde|xfce) is neither by name a VM specific or VM unspecific package. Due to majority Whonix use case it defaults to VM specific.

Not easy to perfect without a lot code duplication / more package maintenance.

For now non-qubes-vm-enhancements-cli gets installed by default even for physically isolated (RPi) builds since it’s a dependency of non-qubes-whonix-gateway-cli.

Maybe non-qubes-vm-enhancements-cli should become a weak recommended package? Similar to how build-steps.d/1700_install-packages handles virtualbox-guest-x11 / spice-vdagent? To keep it installed for users who already have it whonix-legacy/debian/whonix-legacy.preinst could use

apt-mark auto non-qubes-vm-enhancements-cli || true