So I’m seeing that message when booting up both gateway and workstation. Just an FYI my drive is fully encrypted using LUKS, I don’t know if that has something to do with it.
So is this something I can just ignore?
So I’m seeing that message when booting up both gateway and workstation. Just an FYI my drive is fully encrypted using LUKS, I don’t know if that has something to do with it.
So is this something I can just ignore?
It’s not a big deal, can be ignored but we’d like to avoid this error message in order to avoid confusion caused by it.
Are you using initrd generator,
computer@computer-System-Product-Name:~$ dpkg -l | grep dracut
ii dracut-install 060+5-1ubuntu3.3 amd64 dracut is an event driven initramfs infrastructure (dracut-install)
computer@computer-System-Product-Name:~$ dpkg -l | grep initramfs-tools
ii initramfs-tools 0.142ubuntu25.5 all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.142ubuntu25.5 amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.142ubuntu25.5 all generic modular initramfs generator (core tools)
computer@computer-System-Product-Name:~$
Wait. Why is that Ubuntu?
The repart error is inside the VM but you’ve run commands from Find out which initrd Generator is installed on the host operating system? That’s wrong.
These commands should be run inside the VM.
So I ran the commands in workstation
zsh: corrupt history file /home/user/.histfile
[workstation user ~]% dpkg -l | grep dracut
ii dracut 059-4 all Initramfs generator using udev
ii dracut-config-generic 059-4 all dracut is an event driven initramfs infrastructure
ii dracut-core 059-4 amd64 dracut is an event driven initramfs infrastructure (core tools)
ii dracut-live 059-4 all dracut is an event driven initramfs infrastructure (live image modules)
ii grub-live-dracut 3:9.1-1 all grub live dracut dependencies
[workstation user ~]% dpkg -l | grep initramfs-tools
zsh: done dpkg -l |
zsh: exit 1 grep --color=auto initramfs-tools
[workstation user ~]%
No additional information required.
We’ll most likely fix this in the next release.
So it’s a bug?
So I can continue to use Whonix though?
I already answered that in my first post.
To fix:
Optional!
sudo sgdisk --typecode='3:4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709' /dev/sda
Note: No longer required for build version 17.4.0.4
and above. (Unreleased at time of writing.)
Context: Virtual Hard Disk Size Increase
The sgdisk
is required to fix the feature to automatically grow the virtual hard drive file system inside the VM after increasing the size of the virtual hard drive on the host operating system. Once fixed - and it will be fixed by default in 17.4.0.4
and above - running gparted
(disk partitioning tool) inside the VM will no longer be required. This feature should be functional in 17.3.9.9
after the above sgdisk
fix. In any case, the linked wiki page takes precedence and has been updated.
Those not interested in virtual hard drive disk size increase can completely ignore this.
Yeah I’ll ignore it. Thanks.