so far, this is working great. here’s some of the issues i ran into, most being minor:
on a couple laptops that need a synaptics driver, tap-to-click on a touchpad isn’t an easy configuration option. no, this is not a whonix problem. it’s a documented debian buster issue that is fixable with dropping a config file into /etc/apt/xorg.conf.d/. as release gets closer to final, it may be an issue worth addressing for user friendliness.
for the most part, so far, so good. honestly, i’m really excited for “whonix host.” it simplifies so much that, in the past, has taken a lot of pages to document for people.
during first boot of Whonix-Host installed (live [1] or persistent)
And /usr/lib/whonix-libvirt/install is started only once. Because it creates a done file /var/lib/whonix-libvirt/install.done and if that done file exists it won’t run again. That is to get the initial setup done but from then not interfere with the user.
The iso itself is compressed but the contents of the iso aren’t compressed.
If someone upgrades from non-KVM capability to KVM capability, already imported (manually or at first boot) VMs aren’t automatically upgraded to be using KVM. Maybe if KVM failed to be detected there should be a one time popup pointing that out? Warn against performance issues and future non-auto-upgrade to KVM? Warn against security too? Is QEMU considered less secure than KVM in the age of spectre / meltdown?
[1] only if no previous persistent boot.
[2] or better said if KVM is not detected.
I would like to tackle some networking issues/questions I didn’t really pay attention to until now (thus I don’t know if the below described behavior is recent or has always been this way on Whonix-Host).
On installed Whonix-Host in KVM there is a (expected) conflict between the host (i.e. the physical machine) and the guest (i.e. the KVM Whonix-Host VM) virtual virbr0 NAT interfaces as both by default use 192.168.122.0/24.
Problem: I cannot bring up eth0 on installed KVM Whonix-Host even after disabling virbr0:
user@host:~$ sudo ifup eth0
No DHCP client software found!
ifup: failed to bring eth0
Is it related to dhcpcanon which has its own syntax? (btw I still don’t understand why we insist on using dhcpcanon instead of network-manager for DHCP).
Then I noticed that eth0 is defined in /etc/network/interfaces.d/30-kicksecure
auto eth0
iface eth0 inet dhcp
This raises a (maybe very naive and stupid) question:
Why do we need to define the default Ethernet interface on Whonix-Host (and using the old naming system instead of new predictable ones)? Isn’t is supposed to be automatically taken care of by NetworkManager?
I also had a similar issue. “Host” networing was functional (in
VirtualBox) but couldn’t start gateway due to eth0 already being in use.
onion_knight via Whonix Forum:
Is it related to dhcpcanon which has its own syntax? (btw I still don’t understand why we insist on using dhcpcanon instead of network-manager for DHCP).
dhcpcanon might not even be starting due to upstream bugs. Linked in the
dhcpcanon discussion forum. network-manager currently does DHCP.
Why do we need to define the default Ethernet interface on Whonix-Host (and using the old naming system instead of new predictable ones)? Isn’t is supposed to be automatically taken care of by NetworkManager?
Then I don’t know why it failed. Will investigate some more.
Definitely not worth changing it for gw/ws (hardcoded and currently stable across different virtualizers). Maybe worth reconsidering for Whonix-Host though (enable predictable network interface names + remove eth0 definition in /etc/network/interfaces.d/30-kicksecure).
This needs more testing on real hardware I suppose.
user@host:~$ virsh -c qemu:///system net-start "default"
error: Failed to start network default
error: internal error: Network is already in use by interface eth0
The VBOX NAT default interface connecting the Whonix-Host VM to your host uses the same IP range maybe?
Anyway not a blocker I think since Whonix-Host is not really designed to run in a VM.
No. Upgrades installed in Whonix-Host ISO mode are not applied when later installing using calamares installer. These are missing in Whonix-Host installed. No idea why. Maybe calamares copies ISO contents and ignores the overlay. That might be a feature, not a bug.
We’d have to configure KVM to have an external network in a different range however that will break networking since we ship one set of network confs for all non-Qubes versions. I had to figure out a way to make KVM use the same network settings as VBox when we switched off dhcp.
We’d have to configure KVM to have an external network in a different range however that will break networking since we ship one set of network confs for all non-Qubes versions. I had to figure out a way to make KVM use the same network settings as VBox when we switched off dhcp.
Nope has nothing to do with baremetal’s IP management and everything to do with NAT network config for hypervisors. So it has to stay this way to avoid creating different settings for KVM vs Vbox.
Whonix-Host (currently running inside VirtualBox) is now networking is now by network manager. eth0 got automatically assigned 10.0.2.15.
Now Whonix-Host networking (currently running inside VirtualBox) is functional and both gateway and workstation are starting.
Speed in nested virtualization is too slow to test if networking inside VMs is functional but I will assign more RAM and try again. Can also say more when I build a new image that doesn’t require all the manual changes I did during experimentation.
However, maybe likely this will work?
For QEMU support both of these shouldbe removed?
gateway (actually works without removing this):
<vcpu placement='static' cpuset='0'>1</vcpu>
workstation:
<vcpu placement='static' cpuset='1'>1</vcpu>
Removal was required for me inside VirtualBox. Otherwise I was getting cannot set CPU affinity on process error when trying to start workstation.
Whonix tag 15.0.1.3.2-developers-only should build.
Though, only tested with --remote-derivative-packages true. And had a minor hiccup which hopefully was just a one time thing.
dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt
dpkg-deb: error: <decompress> subprocess returned error exit status 2
dpkg: error processing archive /var/cache/apt/archives/calamares_3.2.4-3_amd64.deb (--unpack):
cannot copy extracted data for './usr/lib/x86_64-linux-gnu/calamares/modules/keyboard/libcalamares_viewmodule_keyboard.so' to '/usr/lib/x86_64-linux-gnu/calamares/modules/keyboard/libcalamares_viewmodule_keyboard.so.dpkg-new': unexpected end of file or stream
Errors were encountered while processing:
/var/cache/apt/archives/calamares_3.2.4-3_amd64.deb
