Algernon:
Another problem with the old firmware version is some i2c bug which does not look harmful but it is spamming the logs.
Can log spam kill sd card?
So either live with that or use some custom firmware package in the build scripts?
Yes.
How would “custom firmware package in the build scripts” look like?
Yeah this could occur over time. Messages go to kern.log and the terminal which is kind of annoying. Maybe this could be suppressed somehow.
It would be mostly a more recent raspi3-firmware package + some changes to the kernel commandline in config.txt to enable apparmor + maybe changes for fstab to automount /dev/mmcblk0p1 at /boot + changed network config for dhcp.
btw: whonixsetup needs “ed” package as dependency otherwise it will fail
There is something wrong with git currently.
git clone --jobs=200 --recursive https://github.com/Whonix/Whonix
fails with:
error: no such remote ref 632c12ca5fada0f65dae5385837bbe712f7a6253
Fetched in submodule path 'packages/apparmor-profile-anondist', but it did not contain 632c12ca5fada0f65dae5385837bbe712f7a6253. Direct fetching of that commit failed.Fixed.
From the live thread:
I guess so. It is just the first version and I just put everything needed for a minimal rpi gateway in one package. There is maybe some meta-package which already includes these packages but at the same time does not include more dependencies. I’m not sure about that though.
If the whonix-gateway-rpi package would be the only one using a newly created meta-package it would probably not make too much sense. You’d have two meta-packages instead of one.
But anon-shared-packages-dependencies looks like a good candidate if we remove sdwdate-gui. vbox-disable-timesync would also be not necessary for the rpi but i guess it would not hurt either. bootclockrandomization would install msgcollector which installs a lot of packages, so it would be good to get rid of it.
Some other stuff:
Using some 40*_ file for the interfaces won’t work so either the user does it manually or we create a new network package for the rpi gw and use this as dependency instead of the current package.
If anyone wants to take a look or try to build, patches/diffs can found here:
https://github.com/Whonix/anon-meta-packages/compare/master...Algernon-01:master
https://github.com/Whonix/Whonix/compare/master...Algernon-01:master
You currently need to add tor-control-panel as a dependency to the whonix-gateway-rpi metapackage. You likely also need to manually set the right time and the correct interface address for your upstream router. After that run whonixsetup to enable tor. You currently also need a serial adapter. I could not yet figure out why I just don’t get any output over HDMI. I tested a lot but nothing did help up to now. It worked before with the gui version, so it should not be hardware related.
msgcollector / msgcollector-gui split in progress.
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.
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:
whonix_build_script_build_dependencyAll --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.
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.
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.
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.
Very good!
I am on it now.
Fixed.
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.
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
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.
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.