Whonix for arm64 / Raspberry Pi (RPi)

Development
,
140

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
141

Thank you for still having “dual build” (or how would we coin it) i.e. KVM and VirtualBox images at the same time in mind. This was always hacky having spice-vdaagent in VirtualBox. The above described weak recommended package is hacky.

In future, KVM builds will be created, signed an uploaded by HulaHoop. No more dual builds by me. (Due to increases build workload - Qubes-Whonix, Whonix CLI, Whonix XFCE, hardened debian, custom workstation, what not.) Therefore we might no longer need the dual build support since that wasn’t a clean way to start with. (Otherwise using dual builds these raw images would have both, VirtualBox guest addition as well as spice-vdagent, even though neither is needed there - could cause issues in some point in future.)

Would you like to build, sign and upload these raw images?

1 Like
142

I guess it should not be too much of a difference except for maybe disk space usage.
I also tried the alternative with --vmsize 3500M. It works the same, expanding the disk size to fill the whole device is maybe a little bit easier with this approach.

I can take a look, but I’m not sure how well it would integrate with my build infrastructure. I guess in particular the upload will be very slow.

143

Algernon:

I guess it should not be too much of a difference except for maybe disk space usage.

Alright, so if it doesn’t offend you, it can be left as is.

144

https://github.com/Whonix/Whonix/pull/425

145

https://github.com/Whonix/Whonix/commit/dd7829bff5789a21d3f5fa6f1da6f0926371ca06

grml-debootstrap RPi patches need to be re-applied.

https://github.com/Whonix/Whonix/blob/master/build_sources/rpi-preferences is still required?

146

Still maintained?

Any buster build successful?

147

No. Due to some rather persistent “technical issues” around here I can’t do any builds currently. Probably won’t change in the near future.

2 Likes
148

Is there anything we can change about this for you to be able to build it?

1 Like
149

No, I don’t have any older images. You could try to build a (stretch) version with some 14.* git tag around the beginning of the year. I don’t know if it will buil though and it would be outdated obviously.

Doubtful. I already asked someone for help, nothing came out of this. At the least I’d need some new hardware for my security wellbeing /dedicated buildmachine and for testing (like rpi 3+) and maybe (maybe) some other “infrastructural” changes. Until then I’m limited mostly to theoretical “work”

1 Like
150

https://github.com/Whonix/Whonix/commit/25b306c8e2dcbeae1c37b469c38641e835a56ec2

1 Like
151

Does not build due to grml-debootstrap missing feature and RPi building was never upstreamed.

Back then (Whonix 14, stretch based) https://github.com/Whonix/Whonix/commit/f2a474c1340bb9d57f82ca85171cbc77ec148cf0#diff-6cfb42832786e629f939f5c45178c774 created a fork of grml-debootstrap.

This might be the grml-deboostrap which worked in Debian stretch: https://github.com/Whonix/Whonix/blob/f2a474c1340bb9d57f82ca85171cbc77ec148cf0/help-steps/grml-debootstrap

https://github.com/Whonix/Whonix/pull/419

So what is to do now:

Re-apply the modifications required to grml-debootstrap
https://github.com/Whonix/Whonix/blob/master/help-steps/grml-debootstrap

In other words “rebase the grml-deboostrap modifications from stretch to buster so it can build RPi”.

Ideally implement Rasberry PI (RPI) support · Issue #114 · grml/grml-debootstrap · GitHub

1 Like
152

Diff of the Debian stretch based grml-debootstrap fork looks easy.

diff grml-debootstrap-stretch grml-debootstrap-fork

56c56
< [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='debootstrap'
---
> [ -n "$DEBOOTSTRAP" ] || DEBOOTSTRAP='qemu-debootstrap'
1665c1665
<          remove_configs umount_chroot finalize_vm fscktool ; do
---
>          remove_configs umount_chroot; do

In other words. Only three things.

  • DEBOOTSTRAP=‘qemu-debootstrap’ → done it git master
  • skip finalize_vm (this should just be grub install) → skip grub install done in git master
  • skip fscktool → dunno if required to disable or can be disabled without forking grml-debootstrap
153

Quote @Algernon Rasberry PI (RPI) support · Issue #114 · grml/grml-debootstrap · GitHub

The fsck step was not required. But I guess it can be put in again.

1 Like
154

https://github.com/Whonix/Whonix/commit/cfe2d9ee0d9617f8fae3f777427a971184140007

https://github.com/Whonix/Whonix/commit/4fc1d064107358a259cdbe17522ea8722759d3f1

https://github.com/Whonix/Whonix/commit/2e5b11eeda78b24a3ddc40792b8548135e94bc51

1 Like
155

Whonix git tag 15.0.0.6.0-developers-only might fix the build issues.

1 Like
156

https://github.com/Whonix/Whonix/commit/f21ca78f9aee7dd6a4d78082b107eb039271798d

1 Like
157

Build still broken.

E: Cross building is possible only with the APT dependency resolver

1 Like
158

That very issue is fixed. But more to do.

1 Like
159

I think I know where previous build issues are coming from. Some architecture specific packages. Trying to find a solution.

sent to debian-mentros mailing list:
‘Architecture: all’ with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all

1 Like