Whonix-Host Operating System (OS) ISO

HulaHoop · April 15, 2020, 3:49pm

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

Patrick · April 15, 2020, 4:23pm

HulaHoop via Whonix Forum:

Patrick:

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

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

Patrick · April 15, 2020, 4:35pm

onion_knight via Whonix Forum:

Patrick:

Or keep as is?

Yes!!
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.

onion_knight · April 15, 2020, 9:18pm

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?

onion_knight · April 15, 2020, 9:19pm

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.

onion_knight · April 16, 2020, 8:42am

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).

Patrick · April 17, 2020, 10:42am

onion_knight via Whonix Forum:

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?

Feel free to suggest rewording etc for future releases.

onion_knight · April 17, 2020, 11:03am

Patrick:

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
⚓ T982 use update-initramfs during installation of Whonix-Host
for it.

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.

onion_knight · April 17, 2020, 12:16pm

Great!

Patrick · April 17, 2020, 1:19pm

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/?

HulaHoop · April 19, 2020, 5:42pm

Change ‘kvm’ to:
<domain type='qemu'>

Remove:

  <cpu mode='host-passthrough' check='none'/>

  <pvspinlock state='on'/>

Patrick · April 19, 2020, 6:24pm

Done in whonix-libvirt git master.

tempest · April 19, 2020, 9:28pm

so far, this is working great. here’s some of the issues i ran into, most being minor:

on a couple laptops that need a synaptics driver, tap-to-click on a touchpad isn’t an easy configuration option. no, this is not a whonix problem. it’s a documented debian buster issue with xfce4 that is fixable with dropping a config file into /etc/apt/xorg.conf.d/. as release gets closer to final, it may be an issue worth addressing for user friendliness.

both the gateway and the workstation appear to be configured to be best viewed in fullscreen, where it will scale to the native resolution. this could potentially lead to confusion with a user switching between windows and mistaking the gateway for the workstation. is it worth considering some type of visual distinguishment between the two?

Aside from those two things, no real usability complaints. the installation was straightforward and painless. one thing to be aware of is, on an old lower end dualcore laptop with about 2 gigs of ram, running whonix host from a usb drive with usb2 protocol, caused some various thrashing issues and anomalies. i used the various known commands out there to tweak the journaling/disk writes on the usb drive partition. but, on first boot of the whonix workstation vm, the machine appears to go into a lock state. eventually, mouse control comes back, but then virt-manager says qemu is disconnected, until eventually all the vm windows and virt-manager closes. now, this was not a huge issue since, upon opening virt-manager again, both the gateway and workstation vms were running and they could be opened to continue as usual. i don’t believe there is any applicable project fix that can be done here. i offer it as a consideration for when minimum hardware requirements are addressed.

for the most part, so far, so good. honestly, i’m really excited for “whonix host.” it simplifies so much that, in the past, has taken a lot of pages to document for people.

Patrick · April 20, 2020, 12:32am

2 posts were split to a new topic: enable Debian stable-updates repository by default

onion_knight · April 19, 2020, 10:47pm

Using update-initramfs fails in Calamares installer due to the fact that the installed target still has live-boot related packages (by choice and by design, to allow live-mode in the installed target).

I’ll try and look at that again.

onion_knight · April 19, 2020, 10:52pm

Great, thanks for your review!

Host, gw and ws should be visually distinguishable as of now: greyish background for the host, dark blue for the gw, and greenish for the ws.

tempest:

on an old lower end dualcore laptop with about 2 gigs of ram, running whonix host from a usb drive with usb2 protocol, caused some various thrashing issues and anomalies. i used the various known commands out there to tweak the journaling/disk writes on the usb drive partition. but, on first boot of the whonix workstation vm, the machine appears to go into a lock state. eventually, mouse control comes back, but then virt-manager says qemu is disconnected, until eventually all the vm windows and virt-manager closes. now, this was not a huge issue since, upon opening virt-manager again, both the gateway and workstation vms were running and they could be opened to continue as usual. i don’t believe there is any applicable project fix that can be done here. i offer it as a consideration for when minimum hardware requirements are addressed.

Indeed, this is way below the minimal requirement to run Whonix-Host. I would not expect a smooth experience with less than 4gigs of RAM, see:
https://phabricator.whonix.org/T976

tempest · April 19, 2020, 10:57pm

thanks for your work.

i’ll check again. may be worth considering the color choices because it didn’t stand out. perhaps “black” for the gateway?

it is. however, i’d gotten to work on the same machine in the past without this issue. however, that may have been with stretch as the host, gnome as the de and vbox as virtual machine base. like i said, i don’t think it’s a project issue. simply sharing. if you want, i have a “nonfree” based buster installed on a usb2 drive. could install the kvm packages for whonix on there and see if the same issue occurs. but, i doubt it’s worth it.

Patrick · April 20, 2020, 12:22am

update-initramfs isn’t “totally destroyed”.

ls -la /usr/sbin/update-initramfs*

lrwxrwxrwx 1 root root 26 Dec 7 2017 /usr/sbin/update-initramfs → /bin/live-update-initramfs
-rwxr-xr-x 1 root root 7332 Jul 27 2019 /usr/sbin/update-initramfs.orig.initramfs-tools

/usr/sbin/update-initramfs was modified by pacakge live-tools to be a symlink to /bin/live-update-initramfs

The orignal update-initramfs is still available as /usr/sbin/update-initramfs.orig.initramfs-tools

Could you please have a look at both scripts? Maybe we’ll find the best way to deal with this. Maybe some way to “trick” /bin/live-update-initramfs into calling /usr/sbin/update-initramfs.orig.initramfs-tools (it does that under some conditions).

We can to undo and restore the original update-initramfs or use the original update-initramfs. Full details here: Whonix-Host Operating System (OS) ISO - #231 by Patrick

Either before running the calamares installer:

sudo unlink /usr/sbin/update-initramfs
sudo cp /usr/sbin/update-initramfs.orig.initramfs-tools /usr/sbin/update-initramfs

That might work well enough as a workaround. Something similar could be applied during the build process.

Or modify main.py.dist to run /usr/sbin/update-initramfs.orig.initramfs-tools (with paramater -u? similar to default).

Maybe VirtualBox can be a good tool to conveniently test EFI booting during development? Never tried that yet. Not even with Debian.

Also as weird as that might seem, I guess I am going to add some opt-in debug option to install VirtualBox guest additions on on Whonix-Host KVM iso because that would help during development.

onion_knight · April 20, 2020, 7:34am

Default is update-initramfs -k all -c -t
→ for all installed kernels
→ create new initramfs
→ last flag I have actually no idea!! (-t)

But @Patrick you were right!

Simply update-initramfs by update-initramfs.orig.initramfs-tools in the original main.py script did the trick!

Should I modify the git file accordingly?

Patrick · April 20, 2020, 11:29am

onion_knight via Whonix Forum:

But @Patrick you were right!

Did this help with EFI issues?

Simply update-initramfs by update-initramfs.orig.initramfs-tools in the original main.py script did the trick!

Should I modify the git file accordingly?

Yes, please. That change seems sane either way. Closer to defaults. More
reliable, future proof.