No, it is not empty:
root@test-pc:~# tree -a /home/user/
/home/user/
└── .cache
└── virt-manager
└── virt-xml.log
and:
cat /home/user/.cache/virt-manager/virt-xml.log
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (cli:200) Launched with command line: /usr/share/virt-manager/virt-xml Whonix-Gateway --add-device --filesystem source=/mnt/gateway-shared,target=shared,type=mount,accessmode=mapped
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (cli:214) Requesting libvirt URI default
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (cli:217) Received libvirt URI qemu:///system
[Mon, 15 Jul 2019 13:04:36 virt-xml 13047] DEBUG (virt-xml:53) XML diff:
--- Original XML
+++ Altered XML
@@ -96,5 +96,9 @@
<backend model="random">/dev/urandom</backend>
<address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
</rng>
+ <filesystem type="mount" accessmode="mapped">
+ <source dir="/mnt/gateway-shared"/>
+ <target dir="shared"/>
+ </filesystem>
</devices>
</domain>
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (cli:200) Launched with command line: /usr/share/virt-manager/virt-xml Whonix-Workstation --add-device --filesystem source=/mnt/workstation-shared,target=shared,type=mount,accessmode=mapped
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (cli:214) Requesting libvirt URI default
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (cli:217) Received libvirt URI qemu:///system
[Mon, 15 Jul 2019 13:04:36 virt-xml 13048] DEBUG (virt-xml:53) XML diff:
--- Original XML
+++ Altered XML
@@ -93,5 +93,9 @@
<backend model="random">/dev/urandom</backend>
<address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/>
</rng>
+ <filesystem type="mount" accessmode="mapped">
+ <source dir="/mnt/workstation-shared"/>
+ <target dir="shared"/>
+ </filesystem>
</devices>
</domain>
It has been copied over from the ISO file, meaning it somehow survived the cleaning phase at build time.
Other observations regarding Whonix-Desktop-Calamares-Installer-ISO-15.0.0.3.3:
All tests done with KVM, not real hardware
Whonix-ISO (=BEFORE install, using the live ISO only)
-
Theming is not OK
It uses default debian buster theming:
-
Trying to use Whonix-VM with virt-manager results in fatal error
Error starting network 'Whonix-External': Unable to create bridge virbr1: Package not installed
Same thing for virtual network Whonix-Internal
.
Virtual network ‘default’ fails with
Error starting network 'default': internal error: Network is already in use by interface ens3
- Calamares Installer branding must be changed
It is now using default debian buster branding. I already have suggestions to change the branding, will post in another thread.
Whonix-Desktop on HDD (=AFTER install, without the live ISO)
-
Residual files in /home/user/
As mentioned above:
root@test-pc:~# tree -a /home/user/
/home/user/
└── .cache
└── virt-manager
└── virt-xml.log
-
Newly installed user cannot log in as root or execute a command with sudo rights
This is probably the worst bug of the list. I have no idea where it comes from. It seemed to work last time I did a full build and test… Didn’t dig further, here are the outputs:
Trying to use sudo with sudo rights always fails with “incorrect password” (although it is correct):
test@test-pc:~$ sudo ls
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for q:
Sorry, try again.
[sudo] password for q:
Sorry, try again.
[sudo] password for q:
sudo: 3 incorrect password attempts
su command always gives a “Permission denied” error…
test@test-pc:~$ su -
Password:
su: Permission denied
As I said, I didn’t dig further. Any ideas on how to investigate and solve this weird faulty behavior are welcome.
-
Trying to use Whonix-VM with virt-manager results in fatal error (same error as with ISO)
Error starting network 'Whonix-External': Unable to create bridge virbr1: Package not installed
Same thing for virtual network Whonix-Internal
.
Virtual network ‘default’ fails with
Error starting network 'default': internal error: Network is already in use by interface ens3
-
There seems to be a problem with clock synchronization (lagging one hour behind).