how to close encrypted partition with nested partition table?
If I create an encrypted partition using cryptsetup
cryptsetup -q luksFormat /dev/vdb3 /tmp/pwfile
cryptsetup -d /tmp/pwfile luksOpen /dev/vdb3 pv00
and setup a nested gpt partition table on /dev/mapper/pv00
parted=/sbin/parted
disk=/dev/mapper/pv00
${parted} -s -- "${disk}" mklabel gpt
${parted} -s -- "${disk}" mkpart root 0% "${endp1}GiB"
${parted} -s -- "${disk}" mkpart swap "${endp1}GiB" "${endp2}GiB"
${parted} -s -- "${disk}" mkpart none "${endp2}GiB" "${endp3}GiB"
${parted} -s -- "${disk}" mkpart export "${endp3}GiB" 100%
then the new partitions are listed by lsblk as expected
root@clone:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 254:0 0 8G 0 disk
`-vda1 254:1 0 8G 0 part /
vdb 254:16 0 128G 0 disk
|-vdb1 254:17 0 126M 0 part
|-vdb2 254:18 0 897M 0 part
`-vdb3 254:19 0 120.6G 0 part
`-pv00 252:0 0 120.6G 0 crypt
|-pv00p1 252:1 0 8G 0 part
|-pv00p2 252:2 0 8G 0 part
|-pv00p3 252:3 0 8G 0 part
`-pv00p4 252:4 0 90.6G 0 part
but I cannot close the encrypted partition anymore:
root@clone:~# cryptsetup luksClose pv00
Device pv00 is still in use.
dmsetup info -C shows the nested partitions are not used, but /dev/mapper/pv00 is:
# dmsetup info -C
Name Maj Min Stat Open Targ Event UUID
pv00 252 0 L--w 4 1 0 CRYPT-LUKS2-f2a811407807491b875f414fa61f854d-pv00
pv00p1 252 1 L--w 0 1 0 part1-CRYPT-LUKS2-f2a811407807491b875f414fa61f854d-pv00
pv00p2 252 2 L--w 0 1 0 part2-CRYPT-LUKS2-f2a811407807491b875f414fa61f854d-pv00
pv00p3 252 3 L--w 0 1 0 part3-CRYPT-LUKS2-f2a811407807491b875f414fa61f854d-pv00
pv00p4 252 4 L--w 0 1 0 part4-CRYPT-LUKS2-f2a811407807491b875f414fa61f854d-pv00
AFAIU the nested partitions keep pv00 busy.
Using lvm2 instead of a nested gpt partition table there is no such problem. I can deactivate the volume group using vgchange -an vg00, and pv00 can be closed as expected. Is there a similar command to decommission the nested gpt partition table on /dev/mapper/pv00 without removing it?
You can use kpartx. Create the partition mappings with kpartx -a /dev/mapper/pv00 and remove them with kpartx -d /dev/mapper/pv00. Otherwise you could only manually remove them with dmsetup remove pv00p{1,2,3,4}.
Why is this a problem anyway?
The kernel (device mapper, crypsetup/LUKS, LVM, …) does not support nested partition tables at all. In theory, LUKS 2 could support multiple data segments / partitions on its own accord, but it was never implemented. So there is no support for any of it, end of story.
parted simply "cheats" by creating device mapper linear targets for them (technically the same thing LVM uses for its Logical Volumes). This is done without asking and parted offers no options to control this behavior whatsoever.
So it may look like there is support for this, but for the kernel, this isn’t a partition table at all. Closing and reopening the LUKS device also does not make those partition devices reappear (unless you got some custom udev magic going). You’d have to re-run parted on it but even then they don’t appear, because even parted expects this to be handled by another piece of software.
parted NEWS file mentions it:
- Noteworthy changes in release 3.1 (2012-03-02) [stable]
[…]
Device-mapper devices ( LVM, dmraid ) no longer insert a ‘p’ between the
base device name and the partition number unless the last character of
the base device name is a digit. This brings parted into compliance with
the partition naming of kpartx and "linux since the dawn of time", but
differs from the way that dmraid 1.0.0-rc16-3 operates. A patch to
correct dmraid has been submitted to ataraid-list@redhat.com. Without
this patch, parted and dmraid will both create duplicate partition devices
named /dev/mapper/foo1 and /dev/mapper/foop1.
It mentions dmraid, which is probably the reason why this functionality exists at all. You kind of want to support partition tables that can be found on fakeraid/dmraid setups. In this case, dmraid itself creates the partition devices, so parted doesn’t have to; parted only updates them if you make changes to the partition table.
Nested partition tables aren’t really a thing, if you use them anyway you’ll have to depend on kpartx to manage them since parted only does so as a side effect.
Note that compatibility between parted mappings and kpartx is not entirely guaranteed. These are independent implementations.