Whonix-Host Operating System (OS) ISO

[Patrick]

@onion_knight

To the best of my knowledge it can do both (first copies files over and then can also install/remove packages on demand).

[1] Copying over files, pretty likely, yes. The Whonix host (or any VM) raw image doesn’t contain any installable packages before being converted to iso. Only already installed packages. Apt cache (debs) is cleared during the build process to save space. I doubt calamares somehow reconstructs debs from installed packages.

@onion_knight

In this regard Whonix-Host iso should be as close to the fial Whonix Host installed version as possible.

Makes sense.

@Patrick

Does calamares require networking?

I am not sure, but Whonix-Host needs it anyway otherwise it is rather pointless.

I see requirement for internet by an installer as a disadvantage. User might have to enter wifi credentials twice. It adds more fragility, complexity. Think Tor, VPN, onion repos, connection slowness, data quota, and whatnot.

Debian installer is even worse. Often network cards or wifi adapters requiring nonfree drivers aren’t on the iso. These are only available online. After enabling nonfree repository. And Debian repository is unreachable due to no internet. I’ve seen many users fail at this requirement and use Ubuntu instead.

I guess since calamares copies over iso contents to disk it won’t be needing networking. That’s awesome since lower complexity and saves time.

@onion_knight

So that would mean no user creation question during the installing process?

Correct.

@onion_knight

Like say I would want to create a user John with the installer, I wouldn’t be able to do so?

Custom user names would be unsupported. Username “user” is “the ideal user name”. It should be shared among all users of anonymity distributions. The rationale of this is explained here:

GitHub - Kicksecure/dist-base-files: base files for distributions - several important miscellaneous files, such as /etc/hostname, /etc/hosts, /var/lib/dbus/machine-id and more

I also see this as an advantage of usability. The less questions installers ask, the easier to use.

@onion_knight

What user will I have on first boot on the installed version then?

User user.

@onion_knight

How is anon-base-files supposed to take care of that?

anon-base-files postinst script (anon-base-files.postinst) runs all steps required for user creation during installation of anon-base-files such as adduser, addgroup, pam-auth-update, passwd --lock root.

Now that I understand calamares a bit better as per [1], anon-base-files postinst script would only run during the build process when installed. It currently isn’t re-run during calamares installation - because calamares copies files - we didn’t configure it yet to doesn’t install packages.

The refined plan:

• skip copying files from live iso /home/user folder to installed system
  • if that is not possible use a script to remove any unwanted files either during calamares [preferred] or during first boot
• skip calamares user creation question
  • keep user user as it was already created by anon-base-files during raw image creation build process

Btw why would it be bad if files created in /home/user during live iso use would leak into the installed system? Because live contents should never leak to the disk? Well, that would make sense.

Can you find which calamares module is responsible for copying over the files? Then we might be able to find out how it can be configured and if /home/user can be excluded.

---

Calamares allows to run scripts indeed as per calamares/src/modules/shellprocess/shellprocess.conf at calamares · calamares/calamares · GitHub

[onion_knight]

@Patrick

I see requirement for internet by an installer as a disadvantage. User might have to enter wifi credentials twice. It adds more fragility, complexity. Think Tor, VPN, onion repos, connection slowness, data quota, and whatnot.

Debian installer is even worse. Often network cards or wifi adapters requiring nonfree drivers aren’t on the iso. These are only available online. After enabling nonfree repository. And Debian repository is unreachable due to no internet. I’ve seen many users fail at this requirement and use Ubuntu instead.

I guess since calamares copies over iso contents to disk it won’t be needing networking. That’s awesome since lower complexity and saves time.

I just did a test, and YES Calamares works without networking.
But the way I see it, the Whonix-Host ISO is also supposed to work as a standalone live solution, with virt-manager and Whonix-VM pre-installed. This is why I mean when I say that without networking the whole experience is pretty useless.

@Patrick

The refined plan:

• skip copying files from live iso /home/user folder to installed system
  • if that is not possible use a script to remove any unwanted files either during calamares [preferred] or during first boot
• skip calamares user creation question
  • keep user user as it was already created by anon-base-files during raw image creation build process

I get your idea. No user creation during install, user user is the default expected user on the installed OS.

But then why would you want to skip copying files from live iso /home/user? It could as well stay that way IMHO. User user is expected to have a modern Desktop environment with a couple of folders being there. I don’t see the problem.

@Patrick

Can you find which calamares module is responsible for copying over the files? Then we might be able to find out how it can be configured and if /home/user can be excluded.

You just need to remove the lines - users in /etc/calamares/settings.conf

I just build a Whonix-Host 15.0.0.9.4. All good:
Installs without networking → OK
Installs without user creation → OK
Boots into newly installed system with user user → OK

Things to be done now:
*Modify /etc/calamares/settings.conf
*Remove live-config from /etc/calamares/modules/package.conf (no need to remove it, as it is already not in the ISO, breaks the install otherwise)
*Enable user user auto-login

Things yet to be fixed/decided
*The Whonix VMs still do not boot in the live iso (not in read-only mode)
*When booted in persistent mode (=on the installed version), they should be reverted back to read-write mode, otherwise it won’t work.
*Branding…

[onion_knight]

See pull requests: Pull requests · Kicksecure/libvirt-dist · GitHub

[Patrick_mobile]

@onion_knight

I just did a test, and YES Calamares works without networking.
But the way I see it, the Whonix-Host ISO is also supposed to work as a standalone live solution, with virt-manager and Whonix-VM pre-installed. This is why I mean when I say that without networking the whole experience is pretty useless

Yes. Whonix Host is should have functional network. For sure. But calamares not requiring networking is awesome too.

@onion_knight

But then why would you want to skip copying files from live iso /home/user?

I thought that’s also your suggestion.
Rationale being, activities done in Live (iso) mode shouldn’t end up on hard drive?

@onion_knight

User user is expected to have a modern Desktop environment with a couple of folders being there. I don’t see the problem.

Yes. Files from /etc/skel. Not a contradiction to above. /home/user should be similar to Whonix-Workstation after first boot from hard drive.

[Patrick]

@onion_knight

See pull requests: https://github.com/Whonix/whonix-libvirt/pulls

Very good. Merged. But not tested yet.

[Patrick]

These modules in https://github.com/Whonix/whonix-libvirt/blob/master/etc/calamares/settings.conf… Full quote:

- exec:
  - partition
  - mount
  - unpackfs
  - sources-media
  - machineid
  - fstab
  - locale
  - keyboard
  - localecfg
  - networkcfg
  - hwclock
  - services-systemd
  - bootloader-config
  - grubcfg
  - bootloader
  - packages
  - luksbootkeyfile
  - plymouthcfg
  - initramfscfg
  - initramfs
  - sources-media-unmount
  - sources-final
  - umount

We need to understand these modules at least on a high level.

sources-media

/usr/lib/calamares/modules/sources-media/module.desc executes /usr/sbin/sources-media. Was looking at it. Dunno what it is needed for. Something with sources list. Likely not needed because this is already done in Whonix host raw image / package anon-apt-sources-list.

Generally, we need to know what the installer does so it doesn’t do anything we don’t want it to do.

Therefore this module is a candidate for disabling.

machineid

We want shared machineid by anon-base-files. We don’t want random machineid. (Discussed in forums / documented in anon-base-files.)

calamares/src/modules/machineid/machineid.conf at calamares · calamares/calamares · GitHub

“Whether to create an entropy file” sounds interesting but calamares upstream defaults are entropy: false and entropy-copy: false and package calamares-settings-debian /etc/calamares/modules/machineid.conf isn’t using that either so perhaps better not using module machineid for now.

locale

About timezone. We have package timezone-utc. Hence, this module is probably better disabled.

localecfg

locale should already be correctly set during build process. Hence, this module is probably better disabled.

networkcfg

Not sure. Might be better set by GitHub - Kicksecure/kicksecure-network-conf / Kicksecure Network Configuration

hwclock

Dunno yet if needed.

services-systemd

not needed as per calamares/src/modules/services-systemd/services-systemd.conf at calamares · calamares/calamares · GitHub since does nothing by default and because such things would be configured through Whonix packages.

Generally, I am much more eager to have Whonix packages configure anything. That way it is easier to understand and later on easier to change through upgrades.

bootloader-config

A calamares-settings-debian thing, not calamares upstream thing.

/usr/lib/calamares/modules/bootloader-config/module.desc calls /usr/sbin/bootloader-config

Looks useful.

if [ -d /sys/firmware/efi/efivars ]; then
    echo " * Installing grub-efi (uefi)..."
    DEBIAN_FRONTEND=noninteractive chroot $CHROOT apt-get -y install grub-efi-amd64 cryptsetup keyutils
else
    echo " * install grub... (bios)"
    DEBIAN_FRONTEND=noninteractive chroot $CHROOT apt-get -y install grub-pc cryptsetup keyutils
fi

Though, I wonder if that requires networking. Otherwise we could perhaps cache these packages + dependencies somehow so it would work without internet connection too?

grubcfg

Probably required since it modifies /etc/default/grub depending on configuration (using full disk encryption or not).

bootloader

Probably required.

• /etc/calamares/modules/bootloader.conf
• calamares/src/modules/bootloader/bootloader.conf at calamares · calamares/calamares · GitHub

luksbootkeyfile

Dunno yet.

plymouthcfg

We probably don’t want plymouth. Extra complexity. Experienced some bugs in past. Using it on none of my systems. Whnix VMs also don’t have plymouth.

initramfscfg

Probably required.

initramfs

Probably required.

sources-media-unmount

Similar to sources-media.

sources-final

Similar to sources-media.

[onion_knight]

I did a try after removing all the modules you suggest to disable. It seems some of them were still ran nonetheless…
I’ll try a more thorough process tomorrow.

@Patrick

locale

About timezone. We have package timezone-utc . Hence, this module is probably better disabled.

localecfg

locale should already be correctly set during build process. Hence, this module is probably better disabled.

Would that mean no possibility for the user to choose his location and timezone during install?

[Patrick_mobile]

@onion_knight

Would that mean no possibility for the user to choose his location and timezone during install?

Yes. No possibility.

[onion_knight]

Ok, so we want a minimalist install. Just copy the ISO content, disk creation, grub/bootloader and initramf stuff.

I tried again on 15.0.0.9.4 leaving only the following modules:

sequence:

- show:
  - welcome
  - partition
  - summary

- exec:
  - partition
  - mount
  - unpackfs
  - fstab
  - bootloader-config
  - grubcfg
  - bootloader
  - packages
  - luksbootkeyfile
  - initramfscfg
  - initramfs
  - umount

- show:
  - finished

Seems to work well.
(tested in a KVM VM with msdos partition only, both with encrypted and non encrypted settings)

Install went smoothly, newly installed host returns following values:

user@host:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

user@host:~$ timedatectl
               Local time: Tue 2020-03-10 08:34:55 UTC
           Universal time: Tue 2020-03-10 08:34:55 UTC
                 RTC time: Tue 2020-03-10 08:35:40
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no



user@host:~$ sudo apt update
Hit:1 tor+https://deb.debian.org/debian-security buster/updates InRelease      
Hit:2 tor+https://deb.debian.org/debian buster InRelease                       
Hit:3 tor+https://deb.whonix.org buster InRelease                              
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.

@Patrick

machineid

We want shared machineid by anon-base-files. We don’t want random machineid. (Discussed in forums / documented in anon-base-files.)

calamares/src/modules/machineid/machineid.conf at calamares · calamares/calamares · GitHub

“Whether to create an entropy file” sounds interesting but calamares upstream defaults are entropy: false and entropy-copy: false and package calamares-settings-debian /etc/calamares/modules/machineid.conf isn’t using that either so perhaps better not using module machineid for now.

I am not sure I understand what you mean exactly to achieve here. Do you want the same machine ID on the Host as the Whonix (debootstrap) default (26ada0c0-1165-4098-884d-aafd2220c2c6)? If yes, then I am not sure it is even possible. I removed the machine-id module but still got a new UUID on the installed host:

• Non encrypted install:
  /dev/vda1: UUID="2417b79c-e29f-4ae8-ae3d-8f697859c251" TYPE=“ext4” PARTUUID=“30036c34-01”

• Encrypted install:
  /dev/vda1: UUID=“4a885924-ff5e-4649-8f57-f0a830f16a41” TYPE=“crypto_LUKS” PARTUUID=“d93a7116-01”
  /dev/vda2: UUID=“f210179a-0c07-4fab-8a9b-589f3878565f” TYPE=“crypto_LUKS” PARTUUID=“d93a7116-02”
  /dev/mapper/luks-4a885924-ff5e-4649-8f57-f0a830f16a41: UUID=“0e95d35d-1510-464e-a28b-95f572660c4f” TYPE=“ext4”
  /dev/mapper/luks-f210179a-0c07-4fab-8a9b-589f3878565f: UUID=“4f76d8c5-9705-4ed4-9a7c-715486bb4621” TYPE=“swap”

If you want I could share the whole log of the installation. It’s not too long.

[Patrick]

Awesome!

@onion_knight

Ok, so we want a minimalist install. Just copy the ISO content, disk creation, grub/bootloader and initramf stuff.

Yes, your module list already looks very nice and minimal.

@onion_knight

user@host:~$ locale

Probably good. Could you compare please with workstation VM? Should be probably the same, which would be good.

@onion_knight

user@host:~$ timedatectl

Looks good. Similar to above.

@onion_knight

• Non encrypted install:
  /dev/vda1: UUID="2417b79c-e29f-4ae8-ae3d-8f697859c251" TYPE=“ext4” PARTUUID=“30036c34-01”
• Encrypted install:
  /dev/vda1: UUID=“4a885924-ff5e-4649-8f57-f0a830f16a41” TYPE=“crypto_LUKS” PARTUUID=“d93a7116-01”
  /dev/vda2: UUID=“f210179a-0c07-4fab-8a9b-589f3878565f” TYPE=“crypto_LUKS” PARTUUID=“d93a7116-02”
  /dev/mapper/luks-4a885924-ff5e-4649-8f57-f0a830f16a41: UUID=“0e95d35d-1510-464e-a28b-95f572660c4f” TYPE=“ext4”
  /dev/mapper/luks-f210179a-0c07-4fab-8a9b-589f3878565f: UUID=“4f76d8c5-9705-4ed4-9a7c-715486bb4621” TYPE=“swap”

These (UUID="2417b79c-e29f-4ae8-ae3d-8f697859c251" etc.) are disk uuids. These are not considered yet if these should be shared among all Whonix users. These are not considered machine-id. Terminology. Maybe “an ID” or “a machine specific ID” or something but not what I refer to when saying machine-id which refers only to /etc/machine-id and /var/lib/dbus/machine-id. Quite certain on terminology but not super certain.

/etc/machine-d should be same as dist-base-files/etc/machine-id at master · Kicksecure/dist-base-files · GitHub in Whonix gateway, workstation and host. Same thing for dist-base-files/var/lib/dbus/machine-id at master · Kicksecure/dist-base-files · GitHub.

By not using calamares module machineid we probably will have that result.

[onion_knight]

@Patrick

Probably good. Could you compare please with workstation VM? Should be probably the same, which would be good.

Same result on Whonix-Workstation.

@onion_knight

user@host:~$ timedatectl

Looks good. Similar to above.

Same result on Whonix-Workstation.

@Patrick

These ( UUID="2417b79c-e29f-4ae8-ae3d-8f697859c251" etc.) are disk uuids. These are not considered yet if these should be shared among all Whonix users. These are not considered machine-id. Terminology. Maybe “an ID” or “a machine specific ID” or something but not what I refer to when saying machine-id which refers only to /etc/machine-id and /var/lib/dbus/machine-id. Quite certain on terminology but not super certain.

/etc/machine-d should be same as dist-base-files/etc/machine-id at master · Kicksecure/dist-base-files · GitHub in Whonix gateway, workstation and host. Same thing for dist-base-files/var/lib/dbus/machine-id at master · Kicksecure/dist-base-files · GitHub.

By not using calamares module machineid we probably will have that result.

Ok now I understand.

Same result here on installed Host:

user@host:~$ cat /etc/machine-id 
b08dfa6083e7567a1921a715000001fb
user@host:~$ cat /var/lib/dbus/machine-id 
b08dfa6083e7567a1921a715000001fb

[onion_knight]

Pull request

Update settings.conf

[Patrick]

Merged.

I think it was a good decision to use calamares-settings-debian since Debian sorted out a few Debian specifics with their configs already. Building on top of that is better.

Until now my impression of calamares is really good.

---

There are various calamares upstream config files for modules that we still require:

• calamares/welcome.conf at calamares · calamares/calamares · GitHub
• calamares/partition.conf at calamares · calamares/calamares · GitHub
• calamares/mount.conf at calamares · calamares/calamares · GitHub
• calamares/unpackfs.conf at calamares · calamares/calamares · GitHub
• calamares/fstab.conf at calamares · calamares/calamares · GitHub
• calamares/grubcfg.conf at calamares · calamares/calamares · GitHub
• calamares/bootloader.conf at calamares · calamares/calamares · GitHub
• calamares/packages.conf at calamares · calamares/calamares · GitHub
• calamares/initramfs.conf at calamares · calamares/calamares · GitHub
• calamares/umount.conf at calamares · calamares/calamares · GitHub

^ these need be be understood. We need to check if these defaults are OK or if tweaking is required / advisable.

---

Similar to above the same applies to the following calamares settings files by Debian package calamares-settings-debian:

• calamares/settings.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/bootloader.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/finished.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/fstab.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/luksopenswaphookcfg.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/machineid.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/mount.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/packages.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/unpackfs.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/users.conf · master · Debian Live Team / calamares-settings-debian · GitLab
• calamares/modules/welcome.conf · master · Debian Live Team / calamares-settings-debian · GitLab

A lot configs will overlap calamares upstream vs calamares-settings-debian. I guess calamares-settings-debian will be mostly OK but some tweaks might be needed for Whonix.

[onion_knight]

My understanding is that calamares-settings-debian overrides upstream calamares settings, no?
I can have a look at these files but I will probably not understand all of them I assume we would only look closely at the modules we are actually using, right?

Anything else I could test in the meantime? I was thinking testing again why setting of ro mode fails when booting the ISO.

[onion_knight]

Do we have specific kernel boot flags for Kicksecure (I assume yes)? Then we would probably have to modify/have a look at bootloader.config/grub.cfg modules.

[Patrick]

@onion_knight

I can have a look at these files

Yes, please. I will also look through them but it’s much better if it’s not only me.

@onion_knight

I assume we would only look closely at the modules we are actually using, right?

Yes. Did I post configs of some modules we’d not be using? If so… Indeed. No need to understand configs of modules we are not going to use. Maybe a superficial understanding to make sure we’re not missing something.

@onion_knight

My understanding is that calamares-settings-debian overrides upstream calamares settings, no?

This is correct.
However, I guess it would make sense to understand both upstream calamares and Debian (for the configs we are going to use). And then see if any tweaks are needed.

@onion_knight

I was thinking testing again why setting of ro mode fails when booting the ISO.

Good.

@onion_knight

Anything else I could test in the meantime?

I don’t have a roadmap forward.

@onion_knight

Do we have specific kernel boot flags for Kicksecure (I assume yes)?

Actually a lot…

security-misc/etc/default/grub.d at master · Kicksecure/security-misc · GitHub

@onion_knight

Then we would probably have to modify/have a look at bootloader.config/grub.cfg modules.

Good point.

Two things to distinguish:

• Whonix ISO live boot
• boot of Whonix from HDD after installation

boot of Whonix from HDD after installation: if /etc/grub.d gets copied over as expected and update-grub runs then grub boot config should already correctly pass all linux kernel boot parameters. This again is defined in packages. Therefore we probably don’t need help of calamares to set some linux kernel boot parameters.

Whonix ISO live boot: I don’t know what kernel boot parameters are being used. Same as security-misc sets should be used. Should use the standard way of /etc/default/grub.d / /boot grub.cfg etc. Therefore it might be better to have Whonix ISO live boot use grub instead of syslinux/isolinux if you could make that work?

Could you compare please Whonix VM /proc/cmdline with Whonix Host Hard Drive /proc/cmdline?

Could you compare please Whonix VM /proc/cmdline with Whonix Live ISO /proc/cmdline?

(Not sure about terminology yet. We need easy/consistent use of Live ISO vs Whonix Host Hard Drive Installed. The latter is a bit of a mouthful / a lot to type.)

[onion_knight]

All clear. I’ll have a look into this grub stuff first.

cat /proc/cmdline on Whonix-Workstation-15.0.0.8.7 (KVM):

BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 root=UUID=26ada0c0-1165-4098-884d-aafd2220c2c6 ro console=tty0 console=ttyS0,115200n8 random.trust_cpu=off intel_iommu=on amd_iommu=on slab_nomerge slub_debug=FZP page_poison=1 mce=0 pti=on spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force vsyscall=none quiet

cat /proc/cmdline on Whonix-Host-15.0.0.9.4 (KVM, installed on encrypted VM HDD):

BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 root=UUID=a7a069b1-b644-420a-84ee-230b4b0623b6 ro spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force random.trust_cpu=off intel_iommu=on amd_iommu=on efi=disable_early_pci_dma slab_nomerge slub_debug=FZP page_poison=1 mce=0 pti=on vsyscall=none extra_latent_entropy quiet cryptdevice=UUID=1ab01497-2615-42b6-891b-650a2c15c06a:luks-1ab01497-2615-42b6-891b-650a2c15c06a root=/dev/mapper/luks-1ab01497-2615-42b6-891b-650a2c15c06a resume=/dev/mapper/luks-1ab01497-2615-42b6-891b-650a2c15c06a

There is actually more stuff in the Host version. Maybe some new kernel boot flags were added since 15.0.0.8.7?
But at first glance it seems that config from /etc/grub.d/ has been copied over as expected, therefore your assumption

@Patrick

boot of Whonix from HDD after installation: if /etc/grub.d gets copied over as expected and update-grub runs then grub boot config should already correctly pass all linux kernel boot parameters. This again is defined in packages. Therefore we probably don’t need help of calamares to set some linux kernel boot parameters.

seems correct.

cat /proc/cmdline Whonix-Host-iso-15.0.0.9.4:

BOOT_IMAGE=/live/vmlinuz initrd=/live/initrd boot=live live-config.user-default-groups=libvirt,kvm apparmor=1 security=apparmor ip=frommedia

This is expected, as these values are taken from here: https://github.com/Whonix/Whonix/blob/master/iso/isolinux.cfg

label Whonix Desktop Live VM Live

menu label ^Whonix Desktop Live VM Live

menu default

kernel /live/vmlinuz

append initrd=/live/initrd boot=live live-config.user-default-groups=libvirt,kvm apparmor=1 security=apparmor ip=frommedia

text help

Boot Whonix Desktop Live VM Live image

endtext

Two solutions I see:

• Modify isolinux.cfg
• Replace isolinux by grub (probably better?)

I will try to see how to use grub instead of isolinux.

[Patrick]

@onion_knight

Maybe some new kernel boot flags were added since 15.0.0.8.7?

No, I don’t think so.

@onion_knight

There is actually more stuff in the Host version.

The only extras seems related to host version. Probably added by calamares to /etc/default/grub. cryptdevice=, root= and resume=. These are probably needed and OK.

@onion_knight

This is expected, as these values are taken from here: https://github.com/Whonix/Whonix/blob/master/iso/isolinux.cfg

Makes sense.

@onion_knight

Replace isolinux by grub (probably better?)

Might be better.
Unless isolinux is somehow better nowadays for something still?
Seems like a somewhat complex topic for research.

• grub2 - What is the difference between GRUB and SYSLINUX? - Ask Ubuntu
• Comparison of bootloaders - Wikipedia

@HulaHoop any input on isolinux / syslinux vs grub2?

[Patrick]

Features we care about syslinux vs grub2:

• BIOS boot support
• EFI boot support
• future Secure Boot support
• boot from a real DVD (iso)
• write an iso to USB and be able too boot it
• “Hybrid UEFI GPT + BIOS GPT/MBR boot”
• hybrid DVD / USB (didn’t find exact term)
• and then it is also possible to chain various bootloaders if that is of any use

Dunno. Any best practice? Maybe easier to follow a role model? Any iso image by any (popular) Linux distribution that is highly compatible with most/all of this?

[onion_knight]

Good point. Worth looking at how popular distributions (I am thinking Tails, Ubuntu) solve this. No need to reinvent the wheel. By the way kernel boot flags can be as well modified here, no need for grub at all costs.
https://github.com/Whonix/Whonix/blob/master/iso/isolinux.cfg