On github CI:
+ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Lacks VERSION_ID. Therefore:
+ root_cmd apt-get install --yes virtualbox linux-headers-generic
+ test -z apt-get
+ test '' = 1
+ test -n 1
+ true sucmd_quote
+ su -c '${@}'
Related code:
if test -n "${sucmd_quote:-}"; then
true "sucmd_quote"
# shellcheck disable=SC2016
${sucmd} '${@}'
else
${sucmd} "${@}"
fi
${sucmd} '${@}' I don’t understand. How could that possibly work?
./usr/bin/installer-dist: line 1031: USER: unbound variable
There’s an issue with the error handler.
./usr/bin/installer-dist --non-interactive --dev
installer-dist: [NOTICE]: Current shell: 'bash'
installer-dist: [NOTICE]: Saving Installer user log to: '/home/user/installer-dist-download/logs/80/log.user.txt'.
installer-dist: [NOTICE]: Saving Installer debug log to: '/home/user/installer-dist-download/logs/80/log.debug.txt'.
installer-dist: [NOTICE]: Whonix Xfce for Virtualbox Installer.
installer-dist: [NOTICE]: License agreed by the user by setting non_interactive.
installer-dist: [NOTICE]: Detected system: Kicksecure 16.
installer-dist: [NOTICE]: Detected CPU architecture: x86_64.
installer-dist: [WARN]: Minimum RAM Check: Your systems has a low amount of total RAM: 1116 MB. See:
installer-dist: [WARN]: https://www.whonix.org/wiki/RAM
installer-dist: [WARN]: Virtualization Support Test: No virtualization flag found.
installer-dist: [WARN]: (The virtualization detection is imperfect and might show a false negative warning.)
installer-dist: [WARN]: See user documentation on how to enable virtualization:
installer-dist: [WARN]: https://www.whonix.org/wiki/VirtualBox/Troubleshooting#Enable_VT-x_in_BIOS
installer-dist: [WARN]: Nested Virtualization Test: Nested virtualization detected.
- Possibly a user mistake.
- This installer is designed to run on the host operating system.
- This installer is not designed to be run inside virtual machines.
- For more information about nested virtualization see:
https://www.whonix.org/wiki/Nested_Virtualization
installer-dist: [NOTICE]: Checking if Virtual Machine(s) were already imported.
installer-dist: [NOTICE]: Virtual Machine(s) were imported previously.
installer-dist: [NOTICE]: Starting Virtual Machine(s).
VBoxManage: error: VT-x is not available (VERR_VMX_NO_VMX)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
Waiting for VM "Whonix-Gateway-XFCE" to power on...
installer-dist: [NOTICE]: Current script: ./usr/bin/installer-dist
installer-dist: [NOTICE]: Function executed: start_guest
installer-dist: [NOTICE]: Command executed: return 1
installer-dist: [ERROR]: Error detected. Installer aborted.
installer-dist: [ERROR]: No panic. Nothing is broken. Just some rare condition has been hit.
installer-dist: [ERROR]: There is likely a solution for this problem.
installer-dist: [ERROR]: Try again. If this issue is transient (not happening again) it can be safely ignored.
installer-dist: [ERROR]: Please see Whonix News and Whonix User Help Forum.
installer-dist: [ERROR]: If not already reported, please report this bug!
installer-dist: [BUG]: At line: 1047.
1043
1044 start_guest(){
1045 case "${hypervisor}" in
1046 virtualbox)
* 1047 start_virtualbox
1048 ;;
1049 kvm)
1050 start_kvm
1051 ;;
installer-dist: [ERROR]: Please include the user log and the debug log in your bug report.
installer-dist: [ERROR]: (For file locations where to find these logs, see above.)
installer-dist: [ERROR]: Exit code: 1.
zsh: exit 1 ./usr/bin/installer-dist --non-interactive --dev
Not line start_virtualbox was the “issue”. That was happening at a higher level. The actual command that failed was the vboxmanage command.
(It failed because virtualization was unavailable on purpose for testing purposes. That’s not the issue.)
Would be nicer if the error handler had shown the vboxmanage command. That is a general error handler issue not specifically about vboxmanage.
That’s a related point. If virtualization detection failed, then vboxmanage start vm issues should not be considered bug. I will work on the latter part but not on the error handler.
vboxmanage start vm issues should not be considered bug: Done.
Whonix ™ Linux Installer for VirtualBox (recommended) was blessed stable a while ago and is now the default download link for Linux.
So far so good, 1 issue:
The download command is non-ideal.
curl --tlsv1.3 --proto "=https" --output whonix-installer-xfce --url https://www.whonix.org/installer-dist
"=https" are required for zsh compatibility → related: Change default shell from bash to zsh by default? - #117 by Patrick
--tlsv1.3 by itself is unfortunately insufficient to enforce TLS. --tlsv1.3 is useful to prevent TLS version downgrade attacks. But without --proto "=https" the following command would work..
curl --tlsv1.3 --max-time 180 --output ~/test.txt http://httpforever.com/
It only fails as it should when using:
curl --tlsv1.3 --proto "=https" --max-time 180 --output ~/test.txt http://httpforever.com/
But I might be mistaken. Curl might enforce the correct protocol “https” based on the url starting with “https://” and disallow “http”.
https://manpages.debian.org/bullseye/curl/curl.1.en.html
–proto-default
Tells curl to use protocol for any URL missing a scheme name.An unknown or unsupported protocol causes error CURLE_UNSUPPORTED_PROTOCOL (1).
This option does not change the default proxy protocol (http).
Without this option set, curl guesses protocol based on the host name, see –url for details.
–url
Specify a URL to fetch. This option is mostly handy when you want to specify URL(s) in a config file.If the given URL is missing a scheme name (such as “http://” or “ftp://” etc) then curl will make a guess based on the host.
If you specify URL without protocol:// prefix, curl will attempt to guess what protocol you might want.
PROTOCOLS
curl supports numerous protocols, or put in URL terms: schemes. Your particular build may not support them all.
HTTP(S)
curl supports HTTP with numerous options and variations. It can speak HTTP version 0.9, 1.0, 1.1, 2 and 3 depending on build options and the correct command line options.
Looking at `curl --verbose’ it can also be seen that curl makes a difference for http vs https.
related:
https://phabricator.whonix.org/T673
By looking at the old tickets at curl all of this seems to have improved. So when using https:// there’s no need to use --proto =https. Wiki updated.
new bug on Debian stable (currently: bullseye):
The following packages have unmet dependencies:
virtualbox : Depends: libtpms0 (>= 0.8.0~dev1) but it is not installable
Need to enable backports.
Does not happen on Kicksecure because Kicksecure enables the APT backports repository by default.
Fixed. Along with other improvements.
New version of Whonix Installer has been uploaded just now.
debian 11 vm.
on whonix, the problem doesn’t appear.
dpkg: dependency problems prevent configuration of virtualbox:
virtualbox depends on virtualbox-dkms (>= 7.0.6-dfsg-1~fto11+1) | virtualbox-source (>= 7.0.6-dfsg-1~fto11+1) | virtualbox-modules; however:
Package virtualbox-dkms is not configured yet.
Package virtualbox-source is not installed.
Package virtualbox-modules is not installed.
Package virtualbox-dkms which provides virtualbox-modules is not configured yet.
dpkg: error processing package virtualbox (--configure):
dependency problems - leaving unconfigured
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
virtualbox-dkms
virtualbox
E: Sub-process /usr/bin/dpkg returned an error code (1)
In a Qubes Debian VM or real Debian?
Assuming a Qubes Debian VM:
This is unfortunately an invalid test. In Qubes this is expected to fail. So the log above from what you pasted. It’s because DKMS is failing to compile the VirtualBox kernel module. And that is failing because the kernel in Qubes is “weird”. It’s the dom0 kernel. Not the VM kernel. That causes various issues including this one.
You’d have to use https://www.qubes-os.org/doc/managing-vm-kernels/#using-kernel-installed-in-the-vm.
Should the installer check if it’s run in Qubes and exit with an error or warn that this will likely fail unless using Qubes VM kernel?
Or we could go fancy and check similar as DKMS is doing this when it is saying:
It is likely that xxx.qubes.fc32.x86_64 belongs to a chroot’s host
Also the minimum RAM check might show a false positive warning because of Qubes dynamic RAM assignment. That test should then also be skipped in Qubes.
With these modifications, an installation of VirtualBox inside Qubes would probably succeed. But I didn’t test if any VMs could be actually started and I don’t know if anyone would want that. Maybe useful during development / for testing?
It might still be possible to install VirtualBox in a Qubes Debian VM. The VirtualBox kernel module and VirtualBox VMs would be broken but vboxmanage might be functional. I used this in the past to build Non-Qubes-Whonix from inside a Qubes VM. That might also be handy here for developer testing.
For testing on qubes, I use the dirty mode --allow-errors. But that is not “good” because I just want to skip the precheck, not all the errors.
It is, on whonix vms, it works, but I have to review. Vbox is installed. Of course it can’t start.
I am pushing to the master branch now.
It currently fails in some steps, I will see how to not fail on qubes…, although it might require dealing differently with a lot of the steps.