This question regards creation of custom encrypted full disk setup - that doesn't seem to be (well / at all) documented on the internet.

Basically: idea is to have a full disk (technically partial) encryption setup, with disk split to custom volumes(partitions), protected by single password, without using key files or external boot partition.

Lets start with single fully available hard disk: Main volume group is created: VG1, spanning over entire disk. On it 2 logical volumes VG1/LV1 & VG1/LV2. VG1/LV1 become our ext4 boot partition. VG1/LV2 become our main encrypted partition -> VG1/LV2_C Until this moment this is standard single partition setup, however instead of creating filesystem on it we create physical volume. On this physical volume we create another volume group: VG1/LV2_C/VG2 Then nested volume group is split further into logical volumes based on custom needs resulting in something along following:

VG1/LV1:/boot #unencrypted

VG1/LV2_C/VG2/LVA:/partitionA #encrypted with LV2_C pass

VG1/LV2_C/VG2/LVB:/partitionB #encrypted with LV2_C pass

VG1/LV2_C/VG2/LVC:/partitionC #encrypted with LV2_C pass

etc. etc... (this would seem to also support external /boot partitions, unencrypted volumes (VG1/LV3:), volumes encrypted with separate passwords (VG1/LV4_C:), key files etc.)

My question is - has anyone have any experience with following setup, are there any security/performance/reliability concerns that caused it to be not mentioned anywhere as an option? Topics that would particularly interest me would be:

  • could VG2 compromise LV2_C security?

  • will there be noticeable performance overhead over flat standard encrypted volume?

  • can nested volume groups lead to data loss (i.e. by messing up with pointers or alike)?

  • is this setup actually what it claims it is (like in case of virtualization) or VG2 is created alongside VG1 and just mapped over its volume's space (this question actually overlap with earlier topics.

This is not a go/stay question as I will be evaluating it on test setup (seem to be working fine now although was behaving slightly weird during creation) - however any inputs would help a lot. Please feel free to let me know what you think. Thanks.


This is a really messy setup, and while it can probably be made to work you will be fighting against system scripts all the way. I imagine it is also going to be inefficient - particularly if you need to treat an lv as a physical volume using loopback device. I would not go near this though.

It would not compromise security. Volume loss could occur but is not significantly more likely day-to-day - it would occur when making a mistake mounting/unmounting. I don't believe anything would make claims about this setup. It's very non-standard and fringe.

When I faced a simar challenge I concluded it was easier to re-enter passwords multiple times. Also, depending on what you are trying to do, consider a standards pv/vg/lv setup with the lv being an encrypted device and then use files (mounted using loops if not directly supported) as block devices.

  • Thanks for your answer, I was actually using separately encrypted volumes before, however it didn't seem to work properly on LVM version I was using (it displayed only 1 password prompt and I had to type remaining ones blindly, not unusable but irritating flaw) Regarding scripts and OS configuration, it seem that after initialization system is completely oblivious to underlying filesystem structure so no issues encountered here, I was running some additional tests after recent powerspike+outage event but it doesn't seem any damage was done. – uzer000000 Jun 5 '17 at 12:46
  • About mentioned file solution - using using something similar during truecrypt era, I can tell that this would be too much bother for me to to be dealing with on daily basis (and the software did everything for you there). Anyway, I have setup backup system and data itegrity monitoring scripts - will leave a note if there will be a need to use it. Ciao – uzer000000 Jun 5 '17 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.