Whonix-Host Operating System (OS) ISO

Merged. And made installable. (Solved packaging issue of overwriting file by different package.) Included in Whonix 15.0.1.2.3-developers-only.

But that’s not an ideal solution yet. Might be better to use update-initramfs and stay as close to /usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/main.py as possible?

Therefore…


File /usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/README.md might be slightly outdated (but helpful nonetheless).

live-config debian/changelog says “Moving initramfs-tools scripts content to live-tools.” Alright, so lets look into package live-tools.

debian/live-tools.preinst does

dpkg-divert --package live-tools --quiet --add --rename --divert /usr/sbin/update-initramfs.orig.initramfs-tools /usr/sbin/update-initramfs

debian/live-tools.postrm does

dpkg-divert --package live-tools --quiet --remove --rename --divert /usr/sbin/update-initramfs.orig.initramfs-tools /usr/sbin/update-initramfs

Options:

  • (not preferred) modify /usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/main.py to use /usr/sbin/update-initramfs.orig.initramfs-tools
  • (better but non-ideal) add uninstall live-tools before installing
  • running sudo sh -x /var/lib/dpkg/info/live-tools.postrm remove should work in theory but in practice the script is not idempotent (does not support re-running) therefore uninstallation during calamares package remove step would fail. Possibly a packaging but but that won’t be fixed before bullseye even if reported.
  • sudo apt --yes purge live-tools might help (but then calamares might might choke [1]) Run that command somehow automated after boot?
  • (ideally) Or we could have calamares have apt purge live-tools by modifying /etc/calamares/settings.conf? Module packages removes from chroot not from live disk, right? Invent our own calamars module for apt purge live-tools that runs early?
  • Or keep as is?

[1] We could change /etc/calamares/modules/packages.conf (packages.conf) from remove to try_remove. I.e. failing open rather than closed. Then calamares would be less picky about trying to remove package(s) that are already removed and not consider it a failure. Maybe would ease development?

Had a build error.

+ cd /home/user/whonix_binary
+ sudo mksquashfs /home/user/whonix_binary/Whonix-Host-XFCE_image image/live/filesystem.squashfs -comp xz
Can't find a SQUASHFS superblock on image/live/filesystem.squashfs
Wrong filesystem or filesystem is corrupted!
Failed to read existing filesystem - will not overwrite - ABORTING!
To force Mksquashfs to write to this block device or file use -noappend

Investigating.

https://github.com/Whonix/Whonix/commit/acfc24236a3b20da6c41aa36cb8ba362ed16bdc0

Yes!! :slight_smile:
It works fine now, why not keep as is? I have just built Whonix-Host-XFCE-15.0.1.2.4.iso, did a BIOS encrypted install → everything works!
I don’t think it is desirable to remove live-tools.

1 Like

? (still stuck on the EFI part)

1 Like

onion_knight via Whonix Forum:

In fact we already have an ISO file that boots on EFI and BIOS systems.

What we could not achieve is having an EFI bootable installed Whonix-Host system. Reasons still unknown.

@Patrick, would you maybe consider already releasing Whonix-Host ISO as it is, without EFI support for Calamares installer? This way people could already start to test it and maybe we could gather some feedback on how to fix this issue.

It is a good idea. However, I don’t want to sink Whonix-Host release,
create a bad reputation by releasing low quality software.

Among most important features for Whonix-Host which are not implemented
yet are Whonix-Host firewall and Whonix-Host Tor /
anon-connection-wizard (ACW) configuration.

https://phabricator.whonix.org/T942

https://phabricator.whonix.org/T981

But to get potetial help, maybe a compromise. Using

could add WARNING - Whonix DEVELOPERS-ONLY Preview Version. Will work
it and then something can be published soon.

Work on livecheck for Whonix-Host:

A likely cause is Calamares failing to set boot time flags to allow installs with select unencrypted partitions to work on EFI systems.

https://forum.manjaro.org/t/calamares-cannot-set-esp-flag/8783/2

Related upstream bug report:

Could have been solved in a version more recent than the one frozen in Buster.

1 Like

What about re-adding minimal QEMU support? Would be useful during development. Then one could try Whonix-Host inside VirtualBox or any other virtualizer.

Only two changes required looks like. Changing domain type from kvm to qemu and disabling host cpu passthrough.


virsh -c qemu:///system net-start "Whonix-External"

shows

error: failed to start network Whonix-External
error: internal error: Network is already in use by interface eth0

Any idea how to fix that one?

Could be because I am testing inside VirtualBox but would be useful to fix this nonetheless.

1 Like

The host-boot-popup is done and included in link below.

WARNING - Whonix-Host DEVELOPERS-ONLY Preview Version

DO NOT USE THIS YET AS A USER!

Whonix-Host is unreleased. Not even available for testers. This version is a preview for developers only.

Missing features the the initial release include

See full task list for first release of Whonix-Host.

Help welcome!


Whonix-Host DEVELOPERS-ONLY Preview Version has been uploaded.

The download link should not contain /ova/. I will fix this for the next upload.


(Qemu fixes mentioned in Whonix-Host Operating System (OS) ISO - #239 by Patrick not included in 15.0.1.2.7. Coming in next git tag.)

2 Likes

OK will work on resurrecting it. Any suggestion where you want the config templates?

1 Like

HulaHoop via Whonix Forum:

OK will work on resurrecting it. Any suggestion where you want the config templates?

Great! Maybe no separate xml files. Just what kind of modifications are
required / suggested. If that seems as a workable appraoch.

If sudo virsh capabilities does not contain <domain type='kvm'> then
the xml files are currently in git master copied to a temporary location
and patched before import. For now it’s just two replacements.

   search="<domain type='kvm'>"
   replace="<domain type='qemu'>"

   search="<cpu mode='host-passthrough'/>"
   replace=""

Implemented here:

https://github.com/Whonix/whonix-libvirt/blob/master/usr/lib/whonix-libvirt/install

onion_knight via Whonix Forum:

Yes!! :slight_smile:
It works fine now, why not keep as is?

I don’t know the nuances between update-initramfs and and mkinitramfs.
Looks like update-initramfs adheres config /etc/initramfs-tools/ of
which we have a few.

./packages/swap-file-creator/etc/initramfs-tools/conf.d/30_swap-file-creator.conf
./packages/ro-mode-init/etc/initramfs-tools/scripts/init-premount/livetest
./packages/security-misc/etc/initramfs-tools/hooks/sysctl-initramfs
./packages/security-misc/etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs
./packages/apparmor-profile-everything/etc/initramfs-tools/hooks/apparmor-profile-everything
./packages/apparmor-profile-everything/etc/initramfs-tools/scripts/init-bottom/apparmor-profile-everything

Plus whatever Debian might be doing by default.

While mkinitramfs might ignore that.

Therefore better stick as close to Debian defaults (update-initramfs) as
possible.

Created
use update-initramfs during installation of Whonix-Host
https://phabricator.whonix.org/T982
for it.

Wow that’s great. Downloading now.
Maybe we could put it somewhere else also such as in the News section to give it more visibility?

1 Like

Thanks for the information, will take a look.
In our case however not only encrypted, but also non-encrypted standard EFI install fails. Which is not the case with vanilla Debian Calamares install.

2 Likes

Testing https://download.whonix.org/ova/15.0.1.2.7/Whonix-Host-XFCE-15.0.1.2.7.iso right now (in KVM).

  • Booted into the ISO, started the VMs → OK
  • BIOS encrypted install, rebooting into the installed target (persistent and live mode) → OK
  • Starting the gw/ws VM (both peristent and live-mode) in installed target in persistent mode AND in installed target in live-mode-> OK (disk permissions seem to be fixed!!)

Great!

Only issue I’ve seen so far: the genmon livecheck panel seems broken (always show Live Mode even when in persistent mode).

2 Likes

onion_knight via Whonix Forum:

Wow that’s great. Downloading now.

:slight_smile:

Maybe we could put it somewhere else also such as in the News section to give it more visibility?

Feel free to suggest rewording etc for future releases.

1 Like

mkinitramfs seems to also "adhere config /etc/initramfs-tools/ "

By default it uses /etc/initramfs-tools as its configuration directory.

from man mkinitramfs

FILES
       /etc/initramfs-tools/initramfs.conf
              The   default   configuration   file   for   the   script.   See
              initramfs.conf(5)  for a description of the available configura‐
              tion parameter.

       /etc/initramfs-tools/modules
              Specified modules will be put in the generated image and  loaded
              when  the system boots. The format - one per line - is identical
              to that of /etc/modules, which is described in modules(5).

       /etc/initramfs-tools/conf.d
              The  conf.d  directory  allows  one  to  hardcode  bootargs   at
              initramfs build time via config snippets. This allows one to set
              ROOT or RESUME.  This  is  especially  useful  for  bootloaders,
              which do not pass an root bootarg.

       /etc/initramfs-tools/DSDT.aml
              If  this  file exists, it will be appended to the initramfs in a
              way that causes it to be loaded by ACPI.
1 Like

Great!

1 Like

Not sure reading manpages alone can explain the differences but it’s certainly a good start. Hard to find a justification / explanation why Debian has two tools for update-initramfs (a wrapper) vs mkinitramfs. Intution tells me that the wrapper isn’t entirely useless but the provided benefit is unclear. Looking at the source code. Found one interesting thing.

/usr/sbin/update-initramfs contains:

# Invoke bootloader
run_bootloader()
{
	# invoke policy conformant bootloader hooks
	if [ -d /etc/initramfs/post-update.d/ ]; then
		run-parts --arg=${version} --arg=${initramfs} \
			/etc/initramfs/post-update.d/
		return 0
	fi
}

/usr/sbin/update-initramfs processes this folder:

/etc/initramfs/post-update.d/

This folder could be important.

EFIStub - Debian Wiki mentions /etc/initramfs/post-update.d/zz-update-efistub

Calling that a lead.

Due to these unknown unknowns I very much think better use the Debian defaults for update-initramfs vs mkinitramfs. If we’re lucky it would even solve EFI issues.

Could you please compare functional EFI boot (iso and/or installed) vs failed EFI boot folder /etc/initramfs-tools? Maybe also /etc/grub.d/?