Whonix-Host · Workboard and live-mode · Workboard could use some triage. Tasks required for first public release could be tagged Whonix_15 vs tasks for future work could be left as is.
Personally I donât see any blocker in the two lists.
This may however be a problem (not a blocker to me anyway) if swap is really a concern to you, as Calamares installer creates a swap partition by default: https://phabricator.whonix.org/T904
Solutions:
Donât care (the installation should be on a encrypted disk anyway, swap is encrypted too)
See how we can change Calamares settings so as to not provide a swap partition by default during partition
Regarding host firewall, I have no experience in that. So I am afraid I wonât be able to help much with that.
This being said, a lot of bugs/desired features will probably appear when we can test Whonix-Host (both live and persistent installation) more thoroughly.
Maybe already consider a first âalphaâ build based on what we have (still pending last desktop configuration changes) that multiple people could test and report back?
EDIT:
I forgot this one https://phabricator.whonix.org/T914
Maybe not a blocker, but should definitely be taken care of, as it is inconvenient (as currently needs editing on first boot after Whonix-Host persistent installation in order to make it work).
Yes, ideally there would be a swap file but itâs not super critical as its encrypted swap partition.
Yes, thatâs it for now since calamares does not support swap file support yet.
Not sure that is a good idea. For users with 4 GB RAM and more that might be OK but with less I donât know if we should care and/or if swap would help.
Whonix-Host-15.0.1.0.7-developers-only: field report
I build a new Whonix-Host 15.0.1.0.7, as well as Whonix-Gateway and Whonix-Workstation VMs and tested it out on real hardware. Not an extensive test, just to see if everything works as expected.
First of all, there is one thing important to consider during Whonix-Host build. If gw and ws VMs are not compressed first, the Calamares installation will take hours, and likely fail if not installing on a disk with less than 250 GB capacity. This is because Calamares installer seems to âthinkâ that Whonix VMs really use 100 GB of space each. Compressing the gw and ws disk images BEFORE building Whonix-Host using qemu-img convert solves the problem:
qemu-img convert -f qcow2 -O qcow2
This is just an observation for builders, it is done manually at this stage, but could be added in the whonix-host build process.
Some functionalities to fully support desktop integration of mounting encrypted and non-encrypted disks appear to be missing: this means encrypted partitions must be decrypted and mounted manually (likely related to some polkit configuration nightmareâŠ).
Whonix gw/ws VMs integration
Whonix-VM resolution size is fixed (automatic 1920x1080 on first boot) â great!
Whonix-VMs desktop background colors are currently wrong (inverted: gw uses ws color and ws uses gw color). Couldnât do a pull request as I donât remember what files take care of this
Whonix-Host installed version
Installed Whonix-Host GRUB menuentry is currently âWhonix GNU/Linuxâ â shouldnât it be changed to âWhonix-Host GNU/Linuxâ? Same thing for /etc/motd
persistent-mode-to-read-write half works: after installation, Whonix VMs are correctly set to -disk readonly=off but their file permissions are still read-only (0440). They will fail to boot in virt-manager (Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -drive file=/var/lib/libvirt/images/Whonix-Workstation.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Block node is read-only)
nfts filesystem, mounting disks in thunar: see above
In general, what further tests would you suggest me to perform on an installed Whonix-Host system?
Anything that needs to be fixed to make it sparse indeed?
Related:
I donât understand this command.
-f filename
-O output format
Possible to use long instead of short qemu-img command line parameters?
We convert qcow2 to qcow2? At what point that command says âuse compressionâ?
Does that mean we have to settle for compressed qcow2 images for Whonix-Host ISO and Whonix-Host installed? Performance degradation? Unpack on installed Whonix-Host?
Yeah. Thereâs /etc/motd.d and /etc/issue.d nowadays. Iâd like to port to that.
Itâs just an empiric finding. The term âcompressâ is probably not appropriate. When using qemu-img convert command, the .qcow2 size seems to match its real size, not its virtual potential one:
user@host:~$ sudo ls -lh /var/lib/libvirt/images/
total 5.3G
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 2.5G Mar 24 14:34 Whonix-Gateway.qcow2
-r--r----- 1 root root 2.9G Mar 24 14:34 Whonix-Workstation.qcow2
(instead of 100G before qemu-img).
I didnât notice any performance degradation. Once again, âcompressâ is probably not the right term.
I guess we could probably replace the cp --sparse=always command by qemu-img convert. In my experience, the result is the same, only .qcow2 images âadvertâ their real size when using qemu-img convert.
OK!
OK, so not an issue. Although I prefer it the other way personnally
OK
Ok, will test later
Iâll try to find out whatâs happening with this EFI installation failure. More details on that later.