Will answer other points soonish.
Could you please report a bug against calamares upstream?
Will answer other points soonish.
Could you please report a bug against calamares upstream?
I don’t think it’s a bug.
See /usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/README.md
:
## initramfs module
This module is specific to Debian based distros. Post installation on Debian
the initramfs needs to be updated so as to not interrupt the boot process
with a error about fsck.ext4 not being found.
## Debian specific notes
If you're using live-build to build your ISO and setup the runtime env
make sure that you purge the live-\* packages on the target system
before running this module, since live-config dpkg-diverts update-initramfs
and can cause all sorts of fun issues.
onion_knight via Whonix Forum:
I think I found the reason.
live-boot
packages must be removed on the installed host during Calamarespackages
module. Otherwise Calamares will fail to update initramfs (update-initramfs is disabled live system is running without media mounted on /lib/live/mount/medium
).@Patrick did you modify this file?
live-config-dist/etc/calamares/modules/packages.conf.dist at master · Kicksecure/live-config-dist · GitHub
No. Not that I remember (checked git).
As far as I remember, we used to remove all
live-boot
packages.
live-config was removed here:
Remove ‘live-config’ as it is no longer installed in the iso file.
Breaks Calamares install otherwise.
Could you please (re-)add any missing packages to packages.conf.dist?
See also
/usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/README.md
:## initramfs module This module is specific to Debian based distros. Post installation on Debian the initramfs needs to be updated so as to not interrupt the boot process with a error about fsck.ext4 not being found. ## Debian specific notes If you're using live-build to build your ISO and setup the runtime env make sure that you purge the live-\* packages on the target system before running this module, since live-config dpkg-diverts update-initramfs and can cause all sorts of fun issues.
Now the question is how do we achieve a live-bootable installed Host if we have to remove all live-build packages…
Package grub-live
Depends:
on live-boot
,
live-boot-initramfs-tools
, live-tools
.
I guess purging live-config
since grub-live
is known to work well
inside Whonix VMs?
onion_knight via Whonix Forum:
I don’t think it’s a bug.
See
/usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/README.md
:
Awesome find!
Well, is it enough to add live-config to packages.conf.dist and then
Create main.py by onions-knight · Pull Request #2 · Kicksecure/live-config-dist · GitHub can be avoided?
No.
live-config
is no longer installed in the ISO build, and thus no longer installed in the installed host. We got rid of it not long ago. So we don’t need Calamares packages
module to remove it anymore:
Now, two options:
either we don’t want the installed host to be able to boot into live-mode, and thus we remove all live-boot
related packages from the installed host with Calamares installer (packages
module) at the end of the installation ;
or we want to have default live-mode support on the installed host and thus we have to find a workaround for encrypted support also since it seems that update-initramfs
cannot be performed on a live system by default in Debian (and we need to update the initramfs for encrypted support at the end of the installation).
The workaround I found (might be a better solution, I don’t know) invokes directly mkintramfs
and allows to circumvent this limitation.
This requires to modify the file /usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/main.py
which is provided by the upstream Debian calamares
package (not calamares-settings-debian
).
Since I don’t know exactly how you plan to apply this change during the build, I have put the modified file here for the time being:
Result: we have now a bootable (BIOS) installed host both with persistent and live modes by default, AND with encrypted support.
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:
/usr/lib/x86_64-linux-gnu/calamares/modules/initramfs/main.py
to use /usr/sbin/update-initramfs.orig.initramfs-tools
live-tools
before installingsudo 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?/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?[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.
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
.
? (still stuck on the EFI part)
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.
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.
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
- Whonix-Host EFI booting support
- Whonix Host Firewall for Whonix Host
- Whonix-Host Tor configuration and anon-connection-wizard (ACW)
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.)
OK will work on resurrecting it. Any suggestion where you want the config templates?
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!!
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?
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.