Whonix Desktop Installer with Calamares - field report

Speculation: an old version of helper-scripts (pre.bsh) shipped in Whonix stable is the cause of this. By installing newer helper-scripts before building Whonix, none of this might happen.

I am probably building with a newer version of helper-scripts, hence not able to reproduce.

I’ll be away for some time as usual.

All my build attempts failed, both on the fresh and the old VM.

As of now, I am unable to build Whonix.

Different errors were thrown, I didn’t have time to take note of all of them. I will retry afresh as soon as possible and report back.

1 Like

Building inside Whonix?
Not sure that would help but deleting old pre.bsh might help.
Or getting newer helper-scripts (pre.bsh) from testers repository (i.e upgrade from testers repository).

sudo rm /usr/lib/helper-scripts/pre.bsh
sudo rm /usr/lib/pre.bsh

Also the umask changes (later undone already) might cause some issues.

I am building either in Debian buster VMs (with newest security-misc package) or in Whonix VMs which are updated from testers repository. That might make the difference if you’re using stable or testers version of Whonix.

The “old” VM is an up-to-date debian buster VM. I always built Whonix with it, without problems, until now, where it always fails.
The newer one is a Whonix-Workstation VM, didn’t check the repos I am using.

1 Like

OK, so I recreated a fresh debian buster VM as build machine (not a Whonix Workstation).

First remark: there are a bunch of packages that are needed in order to build Whonix that are not listed in the building documentation and that I had to add manually. Maybe worth updating the documentation?

The good news: the build finally succeeded

Well, it did fail at ././build-steps.d/2550_convert-raw-to-iso**

+++ cp /home/user/whonix_binary/image/boot/isolinux/
cp: missing destination file operand after '/home/user/whonix_binary/image/boot/isolinux/'

As far as I understand the real cause is that I had no directory /usr/lib/syslinux on the building host, and therefore the following cp command could not be executed:
cp /usr/lib/syslinux/modules/bios/* "$WHONIX_BINARY/image/boot/isolinux/"
Installing syslinux package on the building host solved the problem.

ISO seems to work. Boots normally into X. I will do more tests tomorrow.


Yes, sure.

As soon as I know the name of these packages, these can be - depending on the package either added to documentation and/or be added here https://github.com/Whonix/Whonix/blob/master/build-steps.d/1120_prepare-build-machine for automatic installation during build.

Yay! :partying_face:


package https://packages.debian.org/buster/syslinux
contains /usr/lib/SYSLINUX/ (all upper case)

Would you like to add it here

or I could add it there too.

Btw why isolinux / syslinux?

Low priority: worth switching to grub2? Would you know how to do that?

Would grub2 be better for UEFI support?

And would grub2 be better for Secure Boot support?
(enable Linux kernel gpg verification in grub and/or enable Secure Boot by default)

Maybe it doesn’t really matter since if we wanted to be compatible with Secure Boot (on the host) we might be able to combine shim-signed with isolinux/syslinux too?

1 Like

This has a small chance of a regression in next build ( and above but that tag is yet to be created).

Ok, I’ll try to update the list later. Nothing urgent.


Used for legacy bios boot. Not sure why isolinux instead of grub2… Grub2 is used for EFI bios. This is why we have both in the ISO file. If you boot the ISO in EFI mode, it automatically loads the grub loader. See screenshots below (KVM virtualization, not real hardware):

Maybe grub could be used for both ISO legacy and EFI boots? Maybe worth investigating, maybe not. Not sure of the implications/complexity involved.

Don’t know yet.

More to come later on testing ISO!


Sounds really good!

Pretty sure grub2 supports both BIOS booting from ISO (or anywhere) as well as EFI booting.

This is the package which is for BIOS booting (source: grub2): https://packages.debian.org/search?keywords=grub-pc

This is the package which is for EFI booting (source: grub2):

https://packages.debian.org/buster/grub-rescue-pc (source: grub2) has:

  • grub-rescue-floppy.img: floppy image.
  • grub-rescue-cdrom.iso: El Torito CDROM image.
  • grub-rescue-usb.img: USB image.

There is also:


I don’t yet relationship between isolinux, syslinux and grub2.

Not sure too. And low priority. Could be changed anytime later.

Whonix-Host (Kicksecure) Testing Report, v.

All tests done in KVM until now, not yet on hardware.

Addressing first the last list of bugs as per Whonix Desktop Installer with Calamares - field report (skipping issues already reported as fixed)

1. Virtual Machine Manager/KVM

  • New issue with virt-manager (both on ISO and install target): Error connecting to graphical console: Error opening Spice console, SpiceClientGTK missing -> FIXED by adding package gir1.2-spiceclientgtk-3.0 and needed dependencies

2. Calamares Installer

  • Needs correct branding -> still to be done (see also: Whonix Host Calamares Branding Suggestion)
    Problem: shouldn’t we need a complete new branding now that Whonix-Host has been officially relabeled “Kicksecure”? Shouldn’t we be installing Kicksecure on the install target instead of generic “Whonix-Host”? Any existing suggestions for graphical design?

  • Does it work in EFI mode? Still failing in KVM, maybe related to virtualization, will try on real hardware.

3. Whonix-Host install on HDD

  • at least one of the kernel hardening boot parameters somehow messes with the CPU detection on the host -> needs testing on real hardware, see if it still an issue

  • the installed system has no virtual console root access. Very unpractical, especially for a host system. Maybe consider reverting back this recent change for the Whonix-Host version? (see also Restrict root access) -> still to be discussed and decided

4. Miscellaneous

  • power-manager plugin + pulseaudio plugin -> FIXED (and audio working, at least in KVM)

  • The Whonix Host should be graphically differentiated from the Whonix-VMs. Maybe simply a different background image/color? -> still to be done

  • Somehow a user user was created during the build … FIXED

  • By default, the VMs do not start because the virtual disks are not set to readonly in virt-manager -> still in discussion (https://phabricator.whonix.org/T914)
    As of now: Whonix-Gateway/Workstation virtualization using ISO file only works, but disks must be manually set to read-only in virt-manager AND booted in live-mode (expected behavior, but may be overwhelming/unpractical for end-user, at least needs documentation).
    Same problem on the install target.
    Desired behavior: when booting in live-mode, set the disks to read-only (in their xml files, as their file permissions are already 0444). BUT on the install target change .qcow2 files permissions from 0444 to 0644 during the install process (0444 only needed for live ISO. Probably achievable using some Calamares tweaks/scripting to change the permissions when they are copied over. Needs some researches).

  • Currently the live system in ISO mode provides a live-user account with passwordless sudo rights -> can be fixed by addinglive-config.noroot to live ISO boot parameters (but then we need to change calamares polkit to allow its execution by sudoless user) -> still to be discussed and decided

No more new bugs to report as of now. :slight_smile:

Small suggestion: add the “Show Desktop” button on the XFCE4-panel (minimize all windows immediately, very practical when you are overwhelmed with stuff, exists on Windows since ages). It is already installed, just needs to be added in the XFCE4-panel config file.

I will test on real hardware and see how it behaves.

Overall, good progress!

Some screenshots below

Whonix-Host (Kicksecure) booting from the live ISO file in KVM , showing a work session with both Whonix-Gateway and Whonix-Workstation running in live-mode ((nested virtualzation,Tor tab is within the Workstation) and the host system monitor. As expected, a solid amount of RAM is needed (already 5.6 GiB consumed)

Whonix-Host (Kicksecure) grub menu on the install target (KVM), providing both persistent and live-mode options. Both work.


Kicksecure and Whonix Host are independent projects.

Well, Whonix Host and Whonix VMs are based on Kicksecure, but that’s about it.

Kicksecure doesn’t focus on Tor / Whonix integration at all. It might come with Tor installed by default for secure network time synchronization, i.e. sdwdate. The ultimate goal is to move Kicksecure on its own domain name. This may or may never happen due to lack of resources. Depends on how much traction the project will get.

Therefore, no.

I think no - because then the user needs to have two different passwords.

sudo/root is now nicely sorted and documented here:

root login can be enabled by the user as per:

But why root login? Why not login as user and sudo su? What advantage does root login on virtual console give?

Settings disks to read-only when booted in live mode (i.e. ConditionKernelCommandLine=|boot=live) is actually implemented as per https://phabricator.whonix.org/T914#18825
It might not work though. To debug also see that ticket. Also perhaps run manually to see what the script does not or does wrong.

sudo /usr/lib/whonix-libvirt/live-mode-to-read-only

This could be done during the boot process. Another systemd unit file. Similar to that commit https://github.com/Whonix/whonix-libvirt/commit/bb7773e62850fdc76b794500e6bb0c282a55bb2b

Using ConditionKernelCommandLine=!boot=live - i.e. do not do that in when kernel boot parameter includes boot=live.

Or we drop ConditionKernelCommandLine from the systemd unit file and let the script handle chmod change depending on

if grep -qs "boot=live" /proc/cmdline; then
   ## live mode
   true "do things for live mode"
   ## persistent mode
   true "do things for persistent mode"

I can implement that if you like.

But are you sure chmod permissions from 0444 to 0644 is really useful? Once https://phabricator.whonix.org/T914#18825 is fully working, is that still required?

Not passwordless sudo since that circumvnets the security enhancements made through Restrict root access / https://www.whonix.org/wiki/Root.

Yes, why not.

1 Like

“Show Desktop” button is already implemented, see https://github.com/Whonix/whonix-xfce-desktop-config/blob/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml#L44
Works for me in Whonix XFCE VMs in

1 Like



During Calamares install, the user is given the choice of having the same password for administrator user (root) and his newly created user.

My understanding is that when choosing same password, the newly created user is added to sudo group, if not, then he doesn’t have sudo rights. I need to verify this however.

As of now, no user can sudo, sudo su or su - it never works.

That could be great but I’m afraid that changing the permissions in life-mode will result in copying the entire files into RAM (we had this problem before if I remember correctly) before the permission change can be performed. Worth a try.

The script usr/lib/whonix-libvirt/live-mode-to-read-only works when ran manually. It seems to fail during build.

This is easily solved by adding a boot parameter, but then we must address the fact that Calamares needs root rights to run (polkit?).

1 Like

You are right, my mistake, I didn’t see it :slight_smile:

1 Like

This is working in Non-Qubes-Whonix VMs in (broken tb-starter).
( with fixed tb-starter will be tested soon.)

Since Whonix Host builds are skipping creation of user user
i.e. skipping part of https://github.com/Whonix/anon-base-files/blob/master/debian/anon-base-files.postinst
also the following code is skipped

        ## setting password to changeme
        ## How this password was created:
        ## sudo apt-get install whois
        ## mkpasswd
        ## changeme
        ## Resulted in: aTayYxVyw5kDo

           ## Use --encrypted to be able to use a static, precalculated hash for reproducible builds.
           echo "${user_to_be_created}:${password}" | chpasswd --encrypted

           ## old:
           #usermod --append --groups cdrom,audio,dip,sudo,plugdev "$user_to_be_created"
           ## Prefer addgroup over usermod.
           addgroup "$user_to_be_created" cdrom
           addgroup "$user_to_be_created" audio
           addgroup "$user_to_be_created" dip
           addgroup "$user_to_be_created" sudo
           addgroup "$user_to_be_created" plugdev

Most importantly skipped:

addgroup "$user_to_be_created" sudo

Whonix-Host build: To make sudo , sudo su work during ISO Live Boot, at some point these addgroup commands need to be run or some calamares config.

(Optional, not needed, user documentation:) To be able to run su from user user , it is necessary to, see:

Please post output here if you see it failing. Probably/hopefully fixable.

Note: https://www.whonix.org/w/index.php?title=Dev%2FBuild_Documentation%2F15_full&type=revision&diff=51000&oldid=50915

Calamares in Debian integration progress and the way forward in Bullseye:


1 Like

Sorry for my long absence, I was very busy lately. I hope that I will have more time in the coming days/weeks to pursue this matter. Hopefully we can have something ready before the end of the year…
Any help is welcome if someone has some time to spare :slight_smile:
I’ll do a new build from scratch and see what remains to be done, as it’s been so long since I did the last one…


No worries. Yes, please move this forward. Looks like halfway done. Whonix still very much alive and kicking. Kept on merging lots of unrelated (security) enhancements lately. Let me know how things are going.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]