This is a search for project whonix-host
, whonix-15
with status open
.
https://phabricator.whonix.org/maniphest/query/_Obk7yld9FTN/#R
These tasks I think we should get done before the first release aka Whonix-Host release blocker.
All open Whonix-Host tasks (also lower priority, non-blockers):
https://phabricator.whonix.org/maniphest/query/tJZ0eiJ0CrLl/#R
Great, I can take
https://phabricator.whonix.org/T910
https://phabricator.whonix.org/T969
I’ll first start with a new build, see if everything works fine, and test it further.
Whonix-Host-15.0.1.0.7-developers-only: field report
I build a new Whonix-Host 15.0.1.0.7, as well as Whonix-Gateway and Whonix-Workstation VMs and tested it out on real hardware. Not an extensive test, just to see if everything works as expected.
First of all, there is one thing important to consider during Whonix-Host build. If gw and ws VMs are not compressed first, the Calamares installation will take hours, and likely fail if not installing on a disk with less than 250 GB capacity. This is because Calamares installer seems to “think” that Whonix VMs really use 100 GB of space each. Compressing the gw and ws disk images BEFORE building Whonix-Host using qemu-img convert
solves the problem:
qemu-img convert -f qcow2 -O qcow2
This is just an observation for builders, it is done manually at this stage, but could be added in the whonix-host build process.
Results:
Whonix-Host ISO/Calamares
-
Consider changing
/etc/motd
: “Whonix GNU/Linux” → “Whonix-Host GNU/Linux” -
BIOS installation works fine. Installed and tested on real hardware. → great!
-
EFI installation is broken. The installation cannot proceed (more on this later).
-
EFI ISO doesn’t use the current kernel flags, see my pull requests (also replaced “Whonix Desktop” by “Whonix-Host” in both grub.cfg and isolinux.cfg files):
https://github.com/Whonix/Whonix/pull/432
https://github.com/Whonix/Whonix/pull/433 -
Whonix-Host currently does not have ntfs filesystem support. Quite annoying. I suggest adding
ntfs-3g
package. Maybe also consider addingdosfstools
package. Both packages are very lightweight. (“dosfstools consists of the programs mkfs.fat, fsck.fat and fatlabel to create, check and label file systems of the FAT family.” GitHub - dosfstools/dosfstools: dosfstools consists of the programs mkfs.fat, fsck.fat and fatlabel to create, check and label file systems of the FAT family.) -
Some functionalities to fully support desktop integration of mounting encrypted and non-encrypted disks appear to be missing: this means encrypted partitions must be decrypted and mounted manually (likely related to some polkit configuration nightmare…).
Whonix gw/ws VMs integration
- Whonix-VM resolution size is fixed (automatic 1920x1080 on first boot) → great!
- Whonix-VMs desktop background colors are currently wrong (inverted: gw uses ws color and ws uses gw color). Couldn’t do a pull request as I don’t remember what files take care of this
Whonix-Host installed version
-
Installed Whonix-Host GRUB menuentry is currently “Whonix GNU/Linux” → shouldn’t it be changed to “Whonix-Host GNU/Linux”? Same thing for
/etc/motd
-
persistent-mode-to-read-write
half works: after installation, Whonix VMs are correctly set to-disk readonly=off
but their file permissions are still read-only (0440). They will fail to boot in virt-manager (Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -drive file=/var/lib/libvirt/images/Whonix-Workstation.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Block node is read-only
) -
nfts filesystem, mounting disks in thunar: see above
In general, what further tests would you suggest me to perform on an installed Whonix-Host system?
Awesome!
Packages: yes, please add here anon-meta-packages/debian/control at master · Whonix/anon-meta-packages · GitHub
Strange.
Don’t we create a sparse qcow2 image here? //cc @HulaHoop
https://github.com/Whonix/Whonix/blob/master/build-steps.d/2400_convert-raw-to-qcow2#L37
And then don’t we copy the sparse qcow2 image as sparse qcow2 image into the Whonix-Host raw image?
https://github.com/Whonix/Whonix/blob/master/build-steps.d/1800_copy_vms_into_raw#L32
Anything that needs to be fixed to make it sparse indeed?
Related:
I don’t understand this command.
- -f filename
- -O output format
Possible to use long instead of short qemu-img command line parameters?
We convert qcow2 to qcow2? At what point that command says “use compression”?
Does that mean we have to settle for compressed qcow2 images for Whonix-Host ISO and Whonix-Host installed? Performance degradation? Unpack on installed Whonix-Host?
Yeah. There’s /etc/motd.d and /etc/issue.d nowadays. I’d like to port to that.
Hopefully fixed when working on these:
- ⚓ T965 install gvfs by default / fix access LUKS encrypted USB drive with Thunar
- ⚓ T961 fix USB auto mounting bug / document
- ⚓ T966 fix pkexec
Need to make special note to test Whonix-Host too.
I thought the blue color is most friendly, pretty and workstation the place to spend most time. Therefore added there.
Should be doable. That, /etc/issue, /etc/motd could use a ticket.
Please add comment to the ticket.
I guess ⚓ T910 anti-forensics / amnesia testing of Whonix-Host in Live mode is the only major test for now that comes to mind that you’re already aware off. Everything else you seem to have covered already.
It’s just an empiric finding. The term “compress” is probably not appropriate. When using qemu-img convert command, the .qcow2 size seems to match its real size, not its virtual potential one:
user@host:~$ sudo ls -lh /var/lib/libvirt/images/
total 5.3G
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 2.5G Mar 24 14:34 Whonix-Gateway.qcow2
-r--r----- 1 root root 2.9G Mar 24 14:34 Whonix-Workstation.qcow2
(instead of 100G before qemu-img).
I didn’t notice any performance degradation. Once again, “compress” is probably not the right term.
Full command:
qemu-img convert -f qcow2 -O qcow2 /path_to_whonix_vms/whonix_vms.qcow2 /path_to_whonix_binary/whonix_vms.qcow2
I guess we could probably replace the cp --sparse=always
command by qemu-img convert
. In my experience, the result is the same, only .qcow2 images “advert” their real size when using qemu-img convert
.
OK!
OK, so not an issue. Although I prefer it the other way personnally
OK
Ok, will test later
I’ll try to find out what’s happening with this EFI installation failure. More details on that later.
Yes
Maybe the problem onion_knight ran into was caused by incorrect order of operations?
Yes
Seems redundant. qcow2 does the optimal compression by default IIRC. I will read more.
EDIT:
We already do the best we can in the compression department.
Of course the degree of compression you get depends on the amount of zeroed free space in the image, and the amount by which qcow2 is able to compress the other blocks containing data.
qcow2 uses zlib for compression, so the compression won’t be that spectacular. It’s better to keep the filesystems “sparse” in the first place, by ensuring unused disk blocks are zeroed.
For ext2/3 filesystems, Fedora ships a utility called zerofree, which you can either run inside the guest, or run offline from guestfish. This turns unused filesystem blocks into zeroes, which will make outside compression eg with qcow2 much more efficient. For other filesystems, the usual trick is to create a large file of all zeroes until you fill up the free space, then delete it.
As I said I don’t think it’s a compression issue, I think it is related to how Calamares “perceives” the gw/ws VM size when it rsync
the ISO squashfs filesystem into the install target. When copying .qcow2 files created by cp --sparse
it interprets their virtual 101G size as a real size, whereas when copying .qcow2 files obtained with qemu-img convert
, it sticks to their actual size.
See also ls
command output:
user@host:~$ ls -lh Whonix-Gateway-15.0.1.0.7.qcow2
-rw-r--r-- 1 user user 101G Mar 22 18:30 Whonix-Gateway-15.0.1.0.7.qcow2
user@host:~$ cp --sparse=always Whonix-Gateway-15.0.1.0.7.qcow2 Whonix-Gateway-cp-sparse.qcow2
user@host:~$ qemu-img convert -f qcow2 -O qcow2 Whonix-Gateway-15.0.1.0.7.qcow2 Whonix-Gateway-qemu-img.qcow2
user@host:~$ ls -lh Whonix-Gateway-*
-rw-r--r-- 1 user user 101G Mar 22 18:30 Whonix-Gateway-15.0.1.0.7.qcow2
-rw-r--r-- 1 user user 101G Mar 25 18:31 Whonix-Gateway-cp-sparse.qcow2
-rw-r--r-- 1 user user 2.5G Mar 25 18:32 Whonix-Gateway-qemu-img.qcow2
See pull request. Added packages as dependencies for whonix-host-xfce-kvm-freedom. Not sure it’s the right place to have them?
https://github.com/Whonix/anon-meta-packages/pull/22
It’s definitely weird, as during the build qcow2 images are actually created using qemu-img convert
https://github.com/Whonix/Whonix/blob/master/build-steps.d/2400_convert-raw-to-qcow2#L37
But this is an empiric observation that I already did in the past: when using qemu-img convert
in Whonix script, size is kept at 101G (although it’s a virtual size). When using qemu-img convert
manually outside the script on the same files, the resulting qcow2 images are shown as using their real size, i.e. approximately 2.5G. I don’t have an explanation for that. Tested again just now:
user@host:~$ ls -lh Whonix-Gateway-XFCE-15.0.1.0.7.raw
-rw-r--r-- 1 user user 100G Mar 26 22:17 Whonix-Gateway-XFCE-15.0.1.0.7.raw
user@host:~$ qemu-img convert -f raw -O qcow2 Whonix-Gateway-XFCE-15.0.1.0.7.raw Whonix-Gateway-XFCE-15.0.1.0.7.test-qemu-img.qcow2
user@host:~$ ls -lh Whonix-Gateway-XFCE-15.0.1.0.7.*
-rw-r--r-- 1 user user 100G Mar 26 22:17 Whonix-Gateway-XFCE-15.0.1.0.7.raw
-rw-r--r-- 1 user user 2.5G Mar 26 22:20 Whonix-Gateway-XFCE-15.0.1.0.7.test-qemu-img.qcow2
Do you want me to create a ticket on phabricator?
onion_knight via Whonix Forum:
See pull request.
Merged.
Added packages as dependencies for whonix-host-xfce-kvm-freedom. Not sure it’s the right place to have them?
Not sure if perfect but good enough for now. Could be split into a
different package later on that makes clear that it’s non-essential.
Supposing these packages should only be there on an Whonix-Host XFCE
build but not inside VMs.
Do you want me to create a ticket on phabricator?
Yes.
^ Kicksecure-Hosts and Whonix-Hosts will now have grub-live installed by default. I.e. installed Whonix-Host should have the grub live boot menu entries.
When booting the host for the first time it might be interesting to boot into recovery mode. In Whonix VMs I could see that /home/user does not exist yet at that time (no pam mkhomedir run yet), which is expected. Might be interesting for installed Whonix-Host.
Using qemu-img now instead of cp --sparse=always
to hopefully fix sparse file issue.
https://github.com/Whonix/Whonix/commit/7cb5ca4e7f52de5cfd7557655fc05e629e565dd1
See TODO in commit above.
Should we use these qemu-img command line parameters?
-
-p
- progress - that one shouldn’t hurt. -o cluster_size=2M
-o preallocation=metadata
Or would these cause the issue?
15.0.1.0.8-developers-only
includes above fix as well as grub, /etc/issue and /etc/motd branding specific to host, gateway, workstation. Untested.
I’ve just built 15.0.1.0.8-developers-only
/etc/motd
and /etc/issue
are empty (no content inside, applies to Whonix-Host and gw/ws).
Besides, something went completely wrong, VMs were unbootable (“Boot failed: not a bootable disk”).
It seems that this was caused by a faulty qemu-img convert
command in 1800_copy_vms_into_raw
Changing -f raw to -f qcow2 and rebuilding Whonix-Host seemed to fix the issue.
Se my pull request:
https://github.com/Whonix/Whonix/pull/434
More testing later.
Merged, thanks!
This is expected.
Changed files: https://github.com/Whonix/Whonix/commit/f59f94616188d1c3d3fa69b60ec62cdc2ea6aa19
Implementation:
- anon-gw-base-files/etc/issue.d/30_whonix-gateway.issue at master · Whonix/anon-gw-base-files · GitHub
- https://github.com/Whonix/anon-gw-base-files/blob/master/usr/lib/motd.d/30_whonix-gateway.motd
- anon-gw-base-files/etc/default/grub.d/30_whonix-gateway.cfg at master · Whonix/anon-gw-base-files · GitHub
- anon-ws-base-files/etc/issue.d/30_whonix-workstation.issue at master · Whonix/anon-ws-base-files · GitHub
- https://github.com/Whonix/anon-ws-base-files/blob/master/usr/lib/motd.d/30_whonix-workstation.motd
- anon-ws-base-files/etc/default/grub.d/30_whonix-workstation.cfg at master · Whonix/anon-ws-base-files · GitHub
- https://github.com/Whonix/whonix-libvirt/blob/master/etc/issue.d/30_whonix-host.issue
- https://github.com/Whonix/whonix-libvirt/blob/master/etc/default/grub.d/30_whonix-host.cfg
- https://github.com/Whonix/whonix-libvirt/blob/master/usr/lib/motd.d/30_whonix-host.motd
- motd - Debian Wiki on
motd.d
- pam_motd: Display the motd file | pam System Administration | Man Pages | ManKier on
motd.d
- getty(8) — util-linux — Debian buster — Debian Manpages on
/etc/issue.d
motd and issue should now be dynamically created from drop-in configuration folder. Any idea why this isn’t working?
All right, I am making some progress with EFI installation (all tests done in KVM for now, not real hardware).
Previously, Calamares would fail at the very beginning, unable to create an EFI partition. Turns out it needed dosfstools
to do so, which is installed now on the ISO. So fixed.
Then it failed to install grub-efi-amd64
at module bootloader
. This is because it needs module sources-media
in order to have a working apt sources list to download the package. So it seems we will need this module, which creates a temporary sources.list in the chrooted installed environment, as well as module sources-media-unmount
which removes it at the end.
So now theoretically all works well, Calamares installs grub-efi, doesn’t complain and completes the installation. Problem: it won’t boot unless the Whonix-Host ISO is attached:
There is something broken somewhere, or conflicts with something, although Calamares installation logs don’t show anything alarming. I also did an installation with a vanilla live Debian 10 XFCE system with Calamares to compare between the two. I didn’t notice anything out of the extraordinary, logs seem pretty much the same.
I am kind of stuck at this stage. I can’t figure what’s going wrong. I will research some more, I’m sure it must be something really stupid blocking me.
EDIT: comparison of efibootmgr -v
on plain Debian 10 XFCE and Whonix-Host right after Calamares installation:
Debian 10
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0002,0001,0000,0003
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00005 PciRoot(0x0)/Pci(0x6,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0002* UEFI Misc Device PciRoot(0x0)/Pci(0x8,0x0)N.....YM....R,Y.
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Debian HD(1,GPT,1155be0b-252a-46cb-9cd2-735846abcf0c,0x1000,0x96000)/File(\EFI\Debian\shimx64.efi)
Whonix-Host
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0004,0002,0000,0003
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00005 PciRoot(0x0)/Pci(0x6,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0002* UEFI Misc Device PciRoot(0x0)/Pci(0x8,0x0)N.....YM....R,Y.
Boot0003* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Whonix-Host HD(1,GPT,aa03e154-6750-4877-9cc5-9d1fc075184b,0x1000,0x96000)/File(\EFI\Whonix-Host\shimx64.efi)
We see that Whonix-Host bootorder doesn’t default on entry 4. But even after correcting the order manually, it still doesn’t boot…
Still no success. I tried:
- Removing all grub packages and configuration files from the Whonix-Host master raw file, then reburning the ISO
- Running Calamares installer with default settings.conf of Debian (all default modules)
- Manually changing the efi boot order
- Manually reinstalling grub (efi) on the installed host
- Making sure that blkid UUID correspond to grub/efibootmgr entries
- Trying it on real hardware
All to no avail. Still stuck to the “Minimal BASH-like line editing” mode.
I don’t know much about that stuff.
Does Whonix-Host installed have a /boot partition?
Is there file /boot/grub/grub.cfg
?
Could you please compare /boot
from a working EFI system with Whonix-Host installed? There are tools which can compare whole folders such as meld
. Using sudo find /boot
to get a list of all files and compare those working vs non-working.
Which is “50%” done. Meaning, EFI Bios boots until grub-efi.
Maybe that can help to debug. Here is a list of commands there:
Could you try please command ls
?
For inspiration what other commands are useful see file /boot/grub/grub.cfg
from any system that has working EFI booting.
There might also be some commands online how to manually boot.
Anyone we can ask? Grub people on IRC?
irc://irc.gnu.org/grub
Yes. And btw live-mode works (but again, it boots only if the Whonix-Host ISO is attached).
user@host:~$ cat /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
else
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=1024x768
export linux_gfx_mode
menuentry 'Whonix GNU/Linux' --class whonix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-83cbe41d-2c9b-4986-b803-4af882749597' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
else
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
fi
echo 'Loading Linux 4.19.0-8-amd64 ...'
linux /boot/vmlinuz-4.19.0-8-amd64 root=UUID=83cbe41d-2c9b-4986-b803-4af882749597 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 resume=UUID=adfbad2f-cd8a-4fc4-a4cb-14e551d4b5f8
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.19.0-8-amd64
}
submenu 'Advanced options for Whonix GNU/Linux' $menuentry_id_option 'gnulinux-advanced-83cbe41d-2c9b-4986-b803-4af882749597' {
menuentry 'Whonix GNU/Linux, with Linux 4.19.0-8-amd64' --class whonix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-8-amd64-advanced-83cbe41d-2c9b-4986-b803-4af882749597' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
else
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
fi
echo 'Loading Linux 4.19.0-8-amd64 ...'
linux /boot/vmlinuz-4.19.0-8-amd64 root=UUID=83cbe41d-2c9b-4986-b803-4af882749597 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 resume=UUID=adfbad2f-cd8a-4fc4-a4cb-14e551d4b5f8
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.19.0-8-amd64
}
menuentry 'Whonix GNU/Linux, with Linux 4.19.0-8-amd64 (recovery mode)' --class whonix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-8-amd64-recovery-83cbe41d-2c9b-4986-b803-4af882749597' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
else
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
fi
echo 'Loading Linux 4.19.0-8-amd64 ...'
linux /boot/vmlinuz-4.19.0-8-amd64 root=UUID=83cbe41d-2c9b-4986-b803-4af882749597 ro single 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
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.19.0-8-amd64
}
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/11_linux_live ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=1024x768
export linux_gfx_mode
menuentry 'LIVE mode USER (For daily activities.) GNU/Linux, with Linux 4.19.0-8-amd64' --class live --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-8-amd64-advanced-83cbe41d-2c9b-4986-b803-4af882749597' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
else
search --no-floppy --fs-uuid --set=root 83cbe41d-2c9b-4986-b803-4af882749597
fi
echo 'Loading Linux 4.19.0-8-amd64 ...'
linux /boot/vmlinuz-4.19.0-8-amd64 root=/dev/disk/by-uuid/83cbe41d-2c9b-4986-b803-4af882749597 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 boot=live plainroot union=overlay ip=frommedia noeject nopersistence quiet resume=UUID=adfbad2f-cd8a-4fc4-a4cb-14e551d4b5f8
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.19.0-8-amd64
}
### END /etc/grub.d/11_linux_live ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/30_uefi-firmware ###
menuentry 'System setup' $menuentry_id_option 'uefi-firmware' {
fwsetup
}
### END /etc/grub.d/30_uefi-firmware ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
Seems pretty much the same. Just compared with a Debian 10 XFCE install with Calamares.
grub> ls
(proc) (hd0) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0)
This answer here allowed me to boot into Whonix-Host from minimal grub menuentry:
set prefix=(hd0,gpt1)/efi/Whonix-Host
set root=(hd0,gpt1)
insmod linux
insmod normal
normal
But it doesn’t survive reboot. sudo update-grub
doesn’t help either.
My guess is that at this point there is just a little something wrong somewhere that caused a faulty grub configuration… Just need to find it.