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.
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.
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.
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.
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).
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.
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
}
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/?
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.
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).
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.
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
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.