Whonix VirtualBox 14.0.0.6.6 - Testers Wanted!

The easiest way that comes to mind is to change whonixcheck and shared-folder-help to accept ‘qemu’ output. This isn’t a problem because there won’t suddenly be a qemu Whonix version that I don’t know about.

EDIT:
virt-what reports KVM BTW so I find it odd.

EDIT 2:

its a bug in everybody’s most favorite software

HulaHoop:

The easiest way that comes to mind is to change whonixcheck

This is already done, no?

and shared-folder-help to accept ‘qemu’ output.

Yes, if it works, why not.

Perhaps both so we won’t have this issue again.

I had to enable it for all virtualization environments as it doesn’t accept a subset.
https://github.com/Whonix/shared-folder-help/pull/5

Did you change it since this latest test release came out?

After updating vbox to 5.2.6 r120293 Gateway hangs on boot on " NET: register protocol family 38".
Changing network adapters to Intel PRO solves the problem.
Previous version of gateway works fine.
Regards.

Yes saw it in git. I didn’t update since but this is done.

https://github.com/Whonix/shared-folder-help/pull/5/files ConditionVirtualization=1 is not acceptable, since then this would run in VirtualBox as well and fail, which would then be detected and complained by whonixcheck as failed systemd unit.

I guess either

ConditionVirtualization=qemu
ConditionVirtualization=kvm

and/or

ConditionVirtualization=qemu,kvm

or so might do. Please try.

No dice and in the case of the first technique it doesn’t matter what order they are listed in. service nsists on failing if one of the conditions is not satisfied.

A workaround is to essentially create a duplicate service file with the name mnt-shared-qemu.service which has a qemu service. It will be part of the same package of course.

HulaHoop:

No dice and in the case of the first technique it doesn’t matter what order they are listed in. service nsists on failing if one of the conditions is not satisfied.

A workaround is to essentially create a duplicate service file with the name mnt-shared-qemu.service which has a qemu service. It will be part of the same package of course.

I doubt that systemd is so inflexible, without this being reported as
being inflexible.

There is something like “activating condition either or”.

systemd-modules-load.service uses

ConditionDirectoryNotEmpty=|/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d
...

That is activating condition. Multiple of them.

  • systemd triggering condition

So I guess

ConditionVirtualization=|qemu
ConditionVirtualization=|kvm

could work. Could you test please?

1 Like

Works

2 Likes

https://github.com/Whonix/shared-folder-help/commit/2130d872d4e346bc490e70fca79e572d1d1f86df

2 Likes

Hi team,

I wanted to chime in and give user feedback on Whonix 14 as an end user. I’m using VirtualBox latest with the extension pack installed, if that helps to give my context.

  • Great to have 64-bit finally!

  • Yay for KDE 5! I hope this fixes many of the bugs and quirks from the old KDE 4 that I’ve lived with for years in Whonix…

  • It definitely seems snappier.

  • The .onion deb repo servers are cool. I appreciate that it’s slower to download things from it, but the bump in privacy and security is more than welcome. Updates are something of a background task anyway. However, for installing programs it certainly will be noticeable. Again though, it’s something I think most users will accept as worth it.

  • I got a weird KDE crash message upon booting up Workstation for the first time. I should have noted it down but it popped up at least twice at the graphical startup and then I successfully shutted it down via the KDE menu. I thought maybe I had to up to RAM, but saw it was already at 1024MB anyway. So I upped it to about 2.5GB of RAM (and also from 1 to 4 CPUs), booted up, but then got another error. It’s a KdeSudo error: “No command arguments supplied! …” Is it from whonixcheck GUI trying to launch? So, there’s that…it’s weird that Gateway didn’t have this error and gui whonixcheck is all fine in Gateway 14.0.0.6.6.

  • Then in W-W I did a terminal whonixcheck, and in its output got this error: “[WARNING] [whonixcheck] Debian Package Update Check Result: Could not check for software updates! (Timeout reached.) (apt-get code: 124)”. Trying again, it hung on the apt-get check so I just terminated it early.

  • Then i did the usual apt-get updates. Result: fine. A few surprises though (little things seasoned users wouldn’t panic about but beginners would) made me want to test another updated version of whonix 14 though (after the above kdesudo thing is fixed) to make sure it’s perfect normal smoothness as in v13.

  • Where are the default desktop icons? Were they considered unnecessary from now on?

I appreciate that this feedback isn’t of the most helpful dev-level type, I’m only a moderate level Linux user, but still I wanted to give some encouragement and cheer you on from the sidelines. I’m sure you need feedback from more user level anyway.

Any word on when it’ll be released as stable? Is a lot more testing like this needed first? I’m happy to continue to test if you like. Maybe I’ll spend some good time in Whonix 14 just to check it out as a daily driver in order to do that.

And is this the best thread for any bugs or problems I report (in my direct comparison to v13 stable)?

~Turtle~

3 Likes

kdesudo:

Whonix VirtualBox 14.0.0.6.6 - Testers Wanted! - #15 by TechieMike


no desktop icons:
bug, no one knows how to fix it - ⚓ T633 Non-Qubes-Whonix KDE plasma 5 fixes


Prediction is hard.

Yes, all the tickets that were implemented need to be checked if really working in Whonix 14.

Here is a list:
https://phabricator.whonix.org/maniphest/query/8VzYy590CLfu/#R

A lot items might be a bit obscure for users but for example ZeroNet support…
https://phabricator.whonix.org/T597
Does it work? If you could test, then I don’t have to test it.

Also:

Don’t worry too much about it. Whatever works best.

That’s great, thanks. What I’ll do is go through various things I normally do in my Whonix 13, and just report in this thread any bugs I notice. Maybe they’ve already been reported, maybe not, but we can go from there.

Then after that, I might take a look at testing ZeroNet and reporting back, as that interests me. And if that seemed easy enough, who knows, maybe after that other Next# things too.

Happy to help out.

2 Likes
1 Like

Doesn’t actually work (dpkg-mainscript-helper refuses) since the conf files to be deleted were owned by the previously installed packages, not anon-apps-config.

That deleted the config files.

However, still segfault issues. (For example Tor Messenger segfaults as well.) XDG_CONFIG_DIRS still has too many entries.

XDG_CONFIG_DIRS=/usr/share/torbrowser-default-browser/:/usr/share/security-misc/:/usr/share/kde-apper-no-autoupdate/:/usr/share/anon-ws-kde-startmenu/:/usr/share/anon-apps-config/:/usr/share/open-link-confirmation/:/etc/xdg

Which folders/packages are best combined so we can reduce the number of entries?

New testers-only version.