Whonix Linux Installer - Development Discussion

Merged, thanks!

Sure. It’s documented here:

(And can be elaborated if needed.)

Uninstallation isn’t a crucial feature as there’s no demand for it now. Can be revisited later if ever needed.

The added code complexity might indeed make this unjustified.

This is an old idea. Nowadays the way you implemented it such differences such as in package names you defined by operating system specific names (such as Ubuntu vs Debian). Now the correct header package names are already hardcoded. Therefore the header package name auto detection feature doesn’t seem important anymore. Can be moved to rejected features.

Package name looks correct.

Good enough for a generic virtualizer instruction.

1 Like

Awesome job you guys. I wanted to share someone’s implementation of a KVM import script I found that may be helpful to you when working out support for that hypervisor:

1 Like

KVM virtual machine image download support is already supported by the installer.

Other KVM support for KVM import etc. is not planned to be implemented by me. KVM support would need to be added by the maintainer of Whonix KVM, which is only you.

This is because if KVM support isn’t added by the maintainer, the KVM specific commands (import, re-import, network setup) done by the installer versus manual import will always be clouded in mystery what the installer actually does versus what not. That is, if there is an issue with KVM, the installer would always be the first suspect as the source of issues.

It might be the installer’s fault or it might not be. But that investigation should be done by the KVM maintainer. And any changes required for the installer, should also be be done by the KVM maintainer.

Especially with multiple operating system support KVM maintenance seems difficult by looking at the KVM sub forums. For example: Unsupported qcow2 feature extended L2 entries

If I added KVM support, it would be almost the same as taking over KVM maintenance, which is too much.

In other words, by adding KVM support to Whonix Linux Installer, you would be effectively “out of the game” for KVM maintenance.

Major Changes in git:

  • The installer got support for Debian unstable (sid).
  • Debian testing (trixie) support was fixed by installing VirtualBox from Debian unstable (sid) repository.
  • Error out when attempting to use --oracle-repo on Debian testing (trixie) / unstable (sid) because Oracle does not provide such a repository.
  • Use adduser instead of useradd on Debian.
  • Fix launch VirtualBox Manager (GUI). (Do not only start the VMs.)
  • Try to start VMs before trying to start VirtualBox Manager because if it fails, it is less confusing to avoid starting VirtualBox Manager
  • view VirtualBox dkmks make.log on Debian if installation of VirtualBox failed
  • if using --dev and if enabling Kicksecure repository, use Kicksecure developers repository instead of Kicksecure stable repository if Kicksecure repository is needed
  • No longer use mirror by default. Use direct downloads.

New installer uploaded and updated wiki to reflect the name change.

now has a logo:

user.log is empty.

vboxmanage showvminfo exit code might be unreliable to check if a VM exists. Here is an example of a VM that was deleted by deleting the VM data folder in ~/user/VirtualBox VMs/ but not removed from VirtualBox settings folder, which is different (~/. VirtualBox).

vboxmanage showvminfo 2808974a-a2be-4c66-a035-798ffc82b2ad 

Name: <inaccessible!>
UUID: 2808974a-a2be-4c66-a035-798ffc82b2ad
Config file: /home/user/VirtualBox VMs/Whonix-Custom-Workstation/Whonix-Custom-Workstation.vbox
Encryption: disabled
Access error details:
VBoxManage: error: Machine UUID {5b47f67d-b72a-4d04-8f46-b1ab012fb877} in ‘/home/user/VirtualBox VMs/Whonix-Custom-Workstation/Whonix-Custom-Workstation.vbox’ doesn’t match its UUID {2808974a-a2be-4c66-a035-798ffc82b2ad} in the registry file ‘/home/user/.config/VirtualBox/VirtualBox.xml’
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine

Problem is that exit code is 0.

Why did we use sudo --non-interactive -- test -d /usr instead of sudo --validate?

sh compatibility is currently broken.

Not sure if you wish to maintain sh comparability.

./usr/bin/dist-installer-cli: 3515: Syntax error: redirection unexpected

(Line number might be incorrect due to my local development changes.)

It is caused because of this command:

exec > >(tee -a "${log_file_user}") 2> >(tee -a "${log_file_debug}" >&2) &

The command is not even run. sh complains and aborts beforehand.

To demonstrate, just running sh -n which is similar to bash -n which is a simple syntax check without executing the script.

sh -n usr/bin/dist-installer-cli 

usr/bin/dist-installer-cli: 3515: Syntax error: redirection unexpected

By commenting out that command, no more syntax check errors.

Design draft on how the upcoming dist-installer-gui should handle sudo authorization:
Kicksecure Linux Installer - Design Documentation chapter Root in Kicksecure wiki

In function check_vm_exists_virtualbox:

      ## If either one of the Guests exists, proceed.
      if test "${workstation_exists}" = "1" ||
        test "${gateway_exists}" = "1"

This does not have an “else”.

What should happen if either only workstation_exists or only gateway_exists? Any potential bug there in that corner case?

Fixed in git.

Some shellcheck issues on CI.
The CI has probably a newer shellcheck version so it does not happen on Debian bookworm.

Users only know about the problems, they haven’t a vast experience with support requests besides the ones they made.

I noticed an huge decrease in support requests for install of Whonix, although the problem has shifted to installer bugs, which have also decreased over time.

1 Like