Doing LUKS full disk encryption on exisiting system

Is it advisable to do full disk encryption on the host or only on the whonix workstation? Also, I have been searching for a guide to do LUKS full disk encryption over and existing unencrypted system, i. e. both my host ubuntu machine and my whonix workstation, is it possible? Can someone point me to a tutorial? Or should I just put the workstation’s virtual drive inside a truecrypt/veracrypt container the old fashioned way?
Thank you very much for any info.

Good day,

there is no way of doing this, as dm-crypt by default needs to newly format your disk to work. Your best bet would be to safe the drive somewhere, encrypt it and recover it from your backup.

Have a nice day,


1 Like

Yeah everything I’ve subsequently read points to that. Thank you very much for the prompt answer.

Good day,

I’d recommend trying VeraCrypt for this. A guide on full disk encryption using it may be found here: I’d recommend against using TrueCrypt, as there are numerous unpatched bugs in it, see: So about Truecrypt. It's now unsafe

Have a nice day,


Thank you @Ego. Yeah well, veracrypt only supports full disk encryption in Windows. I’ll go for nesting the virtual drives inside a veracrypt container.

1 Like

From what I’ve read in the wiki, essentially, if they get your machine (host) unencrypted, you’re done.

On coming across that and further googling, I understand grub2 can now entertain an encrypted /boot - but I couldn’t come across further details / instructions on doing so.

I’m guessing with such a separate USB /boot partition wouldn’t be necessary. And is apparently not necessary if one can guarantee the physical security of their system. BIOS password, locked case, locked room. I also came across mechanisms to checksum /boot and verify said checksums at boot. The system is still compromised in some fashion, but at least you’re alerted to the fact.

What I have wondered is … assuming an encrypted disk, does it make sense to place the whonix vms inside an encrypted directory within same. Guess not. If they get to your system unencrypted, they can just fire up the vm’s, encrypted or no. Even if one could password a vm, is it really any more of a deterrent than the password you already have on those vms?

From what I have seen, ‘cloning’ a linux system is all but only a disk copy. (mondoarchive can help with that.) So it feels like you could all but cp one disk to another (mounted encrypted), chroot into it to do a few grub tweaks, then swap drives. It feels like most all of the temporary or built files are ignored / recreated at each boot, e.g. /dev, /proc, so migrating could be less of a hassle that it intuitively seems.

Encrypted /boot has limited usefulness indeed.

Just use full disk encryption. The over simplified one line summary of Advanced Security Guide - Whonix would be “any other passwords are of very little to zero use”.

I am not following … “Encrypted /boot has limited usefulness indeed.” then “Just use full disk encryption.” … which would encrypt /boot.

Then, “any other passwords are of very little to zero use”, I’m guessing, is too brief for me to follow what you’re saying.

I would have thought the over simplified one line summary would be: An encrypted image is of marginal usefulness, and will just slow things down; prudence would dictate the image reside within an encrypted system.

None of which addresses encrypted /boot - which your comment appears to be (at least initially) referring to.

In any case … the OP was asking how to get from here to there most easily (unencrypted to not).

In its majority use of the word in instructions all over the internet does not include encrypting /boot. Right, the better use of the word would have been to encrypt 100%. No snappy term describing this prevailed unfortunately.