[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Whonix for arm64 / Raspberry Pi ( RPi )

sdwdate-gui is now in anon-shared-packages-recommended. But that’s not great either. It’s the only gui application in that list. You might want package anon-shared-packages-recommended?

A better split cli vs gui is required. I really want to clean this up otherwise by picking packages things could get forgotten and therefore a non-unified experience / strange bugs.

I think a non-qubes-whonix-gateway-cli package would be great! whonix-gateway-rpi could depend on it plus on what is RPI specific.

msgcollector was split into msgcollector and msgcollector-gui. So just installing msgcollector won’t pull the gui dependencies. It’s not tested yet but I guess it will work ok.

1 Like
   if [ -f "$WHONIX_SOURCE_FOLDER/pkg_list" ]; then
      fi
   true "INFO: Predefined package list detected. Using it for building. "

A user created file in Whonix source code is not great. Whonix buildconfigs are more flexible for that. (Variables and different config folders.)

Could be done similar to this:

All --flavors - including the existing --flavor whonix-gateway could be “equals” in the sense of equality. This would make the code simpler. It’s simpler for all to use opt-in rather than a historic default with workarounds / overrides for new flavors.

  • --flavor whonix-gateway would opt-in non-qubes-whonix-gateway

    whonix_build_script_build_dependency+=" non-qubes-whonix-gateway "

  • --flavor whonix-gateway-rpi would opt-in whonix-gateway-rpi

    whonix_build_script_build_dependency+=" whonix-gateway-rpi "

   ## All architectures currently provided by deb.torproject.org at time of writing.
   architecture_list="armel armhf i386 amd64"
   architecture_list="armel armhf i386 amd64 arm64"

Merged already. And uploaded to Whonix repository.


function get_extra_packages() {

   if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway-rpi" ]; then
   architecture_list+=" arm64"
   fi

No need for that since it only downloads VirtualBox guest additions. Also would break since there is no arm64 builds for guest additions.

We can rename get_extra_packages to a better function name after merging your pull request.

1 Like

anon-meta-packages split into gui and cli in progress.

Are there any packages which would be important for a virtualized cli version of the gateway which are currently not in the whonix-gateway-rpi package? If not I would just split the current whonix-gateway-rpi into non-qubes-whonix-gateway-cli and a new whonix-gateway-rpi.

1 Like

For a robust solution, It should depend on the gateway CLI meta packages… Otherwise it’s hard to know what’s missing now and what may be missing in future.

1 Like

I have split the rpi meta package into a rpi-specific package and a non-qubes-whonix -gateway-cli package. One could change the Depends of the latter one to include mostly meta-packages but there would need to be some more changes to anon-meta-packages:

“anon-shared-packages-recommended” currently depends on gtk2-engines-pixbuf, anon-iceweasel-warning, anon-icon-package which are all gui packages and the first one pulls in a lot of other packages.
“non-qubes-vm-enhancements” depends on acpi-support, pulseaudio, libasound2, alsa-utils. The first two would also install a lot of unnessecary packages.
“whonix-shared-packages-dependencies” depends on grub-enable-apparmor which won’t work for the rpi. Not sure if the package can be included somewhere else.
If (some) of the meta-packages can’t be changed then we need to include the required individual packages into the non-qubes-whonix -gateway-cli package.

2 Likes

Very good!

I am on it now.

Fixed.

https://github.com/Whonix/anon-meta-packages/commit/53b9039bca53b55397a9ee363b3228b8ae9280c1

https://github.com/Whonix/anon-meta-packages/commit/53b9039bca53b55397a9ee363b3228b8ae9280c1

non-qubes-vm-enhancements is for VMs only so should not be installed on CLI gateway anyhow.

About any packages you need which are currently included in non-qubes-vm-enhancements we can maybe later find a solution in a later revision. Let’s see.

What’s happening? Breaks build? Breaks boot? Just doesn’t enable apparmor in grub kernel command line? If it just doesn’t work I guess it’s just a tiny package we could leave it as is until we can repair the package.

Any error message? Perhaps we can fix it?

Ok so the CLI package should be for bare-metal only. The most critical package would be probably initramfs-tools. But maybe it is pulled in somewhere else, maybe even during the initial debootstrap since it is more or less an essential package.
“anon-shared-packages-dependencies” also has vbox-disable-timesync. Would not be required for a CLI gateway but would also not hurt.
“anon-apps-config” could also be removed from “anon-shared-packages-recommended” it mostly changes KDE related settings.

The rpi won’t boot with grub since grub-pc is not available for arm64 and we therefore don’t install it during the grml-debootstrap step.
I did not test it but the script would likely fail during installation of “grub-enable-apparmor” as the postinst script will try to update grub and fail. However, looking at the script again it will always exit 0 and the whole build script won’t break. So it is maybe a non-issue.

1 Like

I see. That would work. However keeping packages installed at debootstrap as minimal as possible is good for the far future. All packages installed there count as “manually installed”. Imagine initramfs-tools is replaced later by a better tool. In that case it’s better if we can remove it from Whonix meta packages, add a replacement package and see initramfs-tools being autoremoveed. Otherwise distribution package management gets harder.

It has also

  • apt config (relevant to cli gw)
  • vlc config (not relevant to cli gw), d
  • systemd-resolved disabling (relevant to cli gw)
  • and more

However the readme is outdated. Will update it now.
So best kept. Also doesn’t interfere with cli gw.

Yes. Probably non-issue. grub-enable-apparmor doesn’t depend on grub. Its postinst using if command -v update-grub >/dev/null 2>&1; then so it’s not even showing an error message. That package was designed with grub not being installed in mind not causing any issues.

The package list would look like:

Package: non-qubes-whonix-gateway-cli
Architecture: all
Pre-Depends: whonix-legacy
Depends: anon-shared-packages-recommended, anon-shared-packages-dependencies, anon-gateway-packages-recommended, whonix-shared-packages-dependencies, anon-connection-wizard, whonix-gateway-packages-dependencies, whonixsetup, tor-control-panel, ${misc:Depends}
Description: Packages for a minimal Whonix gateway
 A metapackage, which installs packages for a non-gui 
 Whonix Gateway.
 .
 Do not remove.

Package: whonix-gateway-rpi
Architecture: all
Pre-Depends: whonix-legacy
Depends: non-qubes-whonix-gateway-cli, rpi-patches, wpasupplicant, firmware-iwlwifi, firmware-atheros, firmware-brcm80211, firmware-ralink, firmware-realtek, iw, fake-hwclock, ${misc:Depends}
Description: Packages for whonix-gateway-rpi
 A metapackage, which installs packages for a non-gui 
 Raspberry Pi 3 Whonix Gateway.
 .
 Do not remove.

The rpi gw builds fine and works. I’d create a new flavor non-qubes-whonix-gateway-cli? and test it. Is there anything missing for a non-rpi amd64 version? Maybe some driver packages, similar to the rpi could be added. Or we leave it as is (and maybe also remove the ones from the rpi meta package) and leave driver installation to the user.

1 Like

That looks very clean already. Last post’s excerpt is ready for merge.

Just a few nits that I would probably fix on top. Wondering why whonixsetup needs to be referenced individually.

non-gui -> CLI

anon-connection-wizard might not be required but not sure but ACW will be merged into tor-control-panel anyhow.

tor-control-panel will not be required anymore in near future. (Once cleanly separated to anon-shaerd-helper-scripts.) Will remove then.

The only way whonixsetup would be installed is as Depends of whonix-gateway-packages-recommended. This, however, would install mostly gui packages so we can’t use it in Depends of the non-qubes-whonix-gateway-cli package.

1 Like

Yes. The package split cli vs gui is not perfect yet. I will add to each package description if it is a gui or cli package.

I am also considering to abolish all the anon- packages and merge them into the whonix- packages for simplification. (No one going to use the anon- packages outside of Whonix.)

Perhaps later I will rename all anon-meta-packages to have a postfix -cli and -gui.

1 Like

Cloning the Whonix repo in the ususal way currently fails with:

“error: no such remote ref c405879185429b23b00b1c1552ddf4c459ca5037
Fetched in submodule path ‘packages/sdwdate’, but it did not contain c405879185429b23b00b1c1552ddf4c459ca5037. Direct fetching of that commit failed.”

All packages from sdwdate to xchat-improved-privacy seem to be affected.

2 Likes

Fixed.

I add to travis to get e-mail notifications when it fails to git clone.

I opened some pull requests for new version of the anon-meta-packages package and general patches to enable build of the rpi and cli gw flavor.
I also tested the non-rpi cli version and it works as expected. Manual network config is still required. For testing it is probably best to not use the normal 100G image size otherwise you need to wait a while when burning to disk. It should fit in around 2G.

2 Likes

How do you make the image bootable?


original grml-debootstrap

[ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap'

vs your fork

[ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='qemu-debootstrap'

This does not necessitate a change.

The syntax [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap' in grml-debootstrap means if variable DEBOOTSTRAP is unset, set it to DEBOOTSTRAP='debootstrap'.

So just set

export DEBOOTSTRAP='qemu-debootstrap'

in build-steps.d/1300_create-raw-image above [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap' add

if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway-rpi" ]; then
   [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='qemu-debootstrap'
fi

What’s the rationale for skipping fscktool?

Anyhow. Disabling it does not require a grml-debootstrap change. If skipping is required, grml-debootstrap gives us the chance to skip it since it is using if [ "$FSCK" = 'yes' ] ; then.

Whonix sets [ -n "$FSCK" ] || export FSCK='yes' but then again that gives you the freedom to set export FSCK='no'

in build-steps.d/1300_create-raw-image above [ -n "$FSCK" ] || export FSCK='yes'

if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway-rpi" ]; then
   ## comment why
   [ -n "$FSCK" ] || export FSCK='no'
fi

finalize_vm you’re skipping because of grub. Unfortunately grml-debootstrap currently does not seem a way to skip grub.

I’ve created a fully untested grml-debootstrap skip-grub branch. Please jump in.

Also created an RPI feature request against grml-debootstrap.


whonixsetup python imports from tor-control-panel now. So you might be able to remove the dependency on anon-connection-wizard. Very minor. You could also wait until we fix the bug and move that code to anon-shared-helper-scripts so whonixsetup does not have the undeclared dependency on tor-control-panel.

How do you mean? The main magic is the 2375_build_rpi_fs_script which creates a bootable fat partition and moves kernel/initrd/firmware over there and the rpi-patches package which installs the firmware files. Images are tested on an RPI 3 B.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]