Does whonix still run in Kicksecure?

Support
1

I can’t seem to get whonix to launch after installing using:

whonix-lxqt-installer-cli

I know I have had it installed maybe a year or so ago but I can’t work out what I have done differently…

2

It should still work if you run it from within a sysmaint session. If it doesn’t work when run from a sysmaint session, please post the full log from the installation attempt here so we can find the issue.

You can also install VirtualBox using virtualbox-installer-cli in a sysmaint session, then import the Whonix OVA manually, if the fully automatic installation doesn’t work for some reason.

1 Like
3

Yeah, I still get the same problem when trying to launch the VMs after install. The logfiles are about triple the character limit to paste here.

(Deleted irrelevant VBox logs for concision)

4

(I deleted the irrelevant VBox logs as my scrolling thumb is getting a sprain).

5

(Deleted irrelevant VBox logs for concision)

8

Oh, sorry, I thought the installation itself was erroring out, whereas this is a VM launch failure.

The relevant part of the log looks like:

00:00:01.516451 VT-x is being used by another hypervisor (VERR_VMX_IN_VMX_ROOT_MODE).
00:00:01.516452 VirtualBox can’t operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE)}, preserve=false aResultDetail=-4011

Are you running any KVM virtual machines at the same time? If so, shut them down; VirtualBox and KVM cannot both run VMs simultaneously.

If you aren’t running any KVM VMs, boot into sysmaint mode, and check which VirtualBox package you have installed with apt list --installed | grep virtualbox. It should be virtualbox-7.2; if you see virtualbox-7.1, install virtualbox-7.2 instead. Earlier versions of VirtualBox had a conflict with KVM that could cause this issue even if no KVM VMs were running, whereas newer, actively supported versions no longer have this issue.

1 Like
9

I just did a stock fresh install of kicksecure and then the whonix install script.

Says I have virtualbox-7.2.16-174877 installed

10

Hmm, that’s weird. Will investigate.

1 Like
11

I have done this twice in a row:

Installed fresh latest Kicksecure, updated, rebooted etc.

Ran the whonix-lxqt-installer-cli, rebooted etc.

Unable to start the whonix VMs in Virtualbox.

I might try the a third time on a different machine just to bracket out the hardware factor (though it was a T480 with 24GB RAM, VTx, VTd etc). I’ll try on a T440p and see if I get the same result.

UPDATE:

I repeated the installation of Kicksecure host and whonix-lxqt-installer-cli on a T440p and have the same issue.

12

Whonix-side discussion:

1 Like
13

So it turns out this is a bit of a mess, but thankfully also an easy fix (for now…).

  • Linux 6.12 takes control of virtualization features of the CPU even when no KVM virtual machines are running. This prevents VirtualBox VMs from running unless the kernel module option kvm.enable_virt_at_load=0 is set. Kicksecure previously set this option by default since it ships kernel 6.12.
  • Virtualbox 7.2.2 implemented a fix for this, but it only works with kernel 6.16.0 and higher. I did not realize there was a kernel version limitation here.
  • VirtualBox later introduced a bug where trying to start a VM while kvm.enable_virt_at_load=0 was set would trigger a kernel panic.
  • In response, I submitted a change to Kicksecure that make kvm.enable_virt_at_load=0 no longer set by default, thinking that modern VirtualBox didn’t need it anymore.
  • Apparently no one noticed this was an issue until just recently? Maybe an older Debian kernel has the APIs from kernel 6.16.0 backported into it, but the most recent kernels don’t? I have no idea, but in any event, now we’re in a situation where VirtualBox VMs just don’t start.

As a temporary stop-gap solution, boot into a sysmaint session, run sudo nano /etc/modprobe.d/fix-vbox.conf, then type in options kvm enable_virt_at_load=0. Press Ctrl+S to save, press Ctrl+X to exit, and then reboot into a user session. VirtualBox should now work normally, as long as you have a new enough version of VirtualBox installed.

I’ll submit a change to re-add the option. Hopefully VirtualBox won’t start triggering kernel panics because of it again.

2 Likes
14

When should we expect the change to take place if you dont mind me asking, while the fix works i dislike meddling with files if not absolutely necessary.

15

Not sure, we don’t usually have ETAs on most things. That being said, I committed the fix to my fork of usability-misc and pinged Patrick about merging it, so it should land as soon as it’s able to.

1 Like