Whonix for arm64 / Raspberry Pi (RPi)

Development
,
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
160

Guide for cross compiling and verifying that the binaries are really compatible for the other platform:

http://jensd.be/800/linux/cross-compiling-for-arm-with-ubuntu-16-04-lts

1 Like
161

We don’t have any packages supporting cross compilation. [1] These “special” packages are amd64 only (Intel and AMD) at the source code level. For example LKRG is linux, amd64 only. It’s non-trivial to port them to other architectures.

A guide on “how to cross compile” won’t cut it. A guide “how to cross compile” would work if these were simple packages similar to the hello package which does not have any architecture specific source code.

But this isn’t a compilation issue. This is only a packaging issue. The issue is described here:
https://lists.debian.org/debian-mentors/2019/11/msg00149.html

Got an answer here and it looks like there isn’t any solution without proverbially biting any bullet:
https://lists.debian.org/debian-mentors/2019/11/msg00156.html

This is currently breaking distro-morphing / Installation from Repository.

[1] At least none where that’s worth it. For packages that support cross compilation, that is already supported. kloak can be cross compiled on amd64 for “i386” (more “i686”). Not interesting/worth it though due to this. What would be interesting / worth it though would be to cross compile to arm64 which however has issues which probably only upstream can solve.

Cross compiling hardened malloc to arm64 would be interesting / worth it but upstream already said it’s not possible:

1 Like