+ 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
Yes!!
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.
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.
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/?