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:
E: Sub-process /usr/bin/dpkg returned an error code (1)
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.
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.
2023-03-31T08:47:09.4130706Z + sudo -- echo 'Successful root login'
2023-03-31T08:47:09.4131187Z installer-dist: [e[1me[32mNOTICEe[0m]: Executing: $ sudo -- echo Successful root login
2023-03-31T08:47:09.4191738Z We trust you have received the usual lecture from the local System
2023-03-31T08:47:09.4192125Z Administrator. It usually boils down to these three things:
2023-03-31T08:47:09.4192447Z #1) Respect the privacy of others.
2023-03-31T08:47:09.4192690Z #2) Think before you type.
2023-03-31T08:47:09.4192976Z #3) With great power comes great responsibility.
2023-03-31T08:47:09.4193653Z sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
2023-03-31T08:47:09.4194198Z sudo: a password is required
2023-03-31T08:47:09.4200564Z + return 1
2023-03-31T08:47:09.4200940Z + die 1 'Failed to run test command as root.'
2023-03-31T08:47:09.4201477Z + log error 'Failed to run test command as root.'
2023-03-31T08:47:09.4201875Z + test 1 = 1
Needs setting up passwordless sudo.
(Based on Kicksecure /etc/sudoers.d/user-passwordless)
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
Probably needs to be setup by .github/workflows/builds.yml.