cryptsetup: "c_swap_unformatted" still exists after system boot

[Swâmi Petaramesh]

Binary package hint: cryptsetup

Using Karmic,

cryptsetup version : 2:1.0.6+20090405.svn49-1ubuntu7.2 (fix commited after bug #475936)

Confirmed after several machines boots : When using random encrypted swap, both "/dev/mapper/c_swap" and "/dev/mapper/c_swap_unformatted" exists after machine has finished booting, where "/dev/mapper/c_swap_unformatted" should have disappeared.

# ll /dev/mapper/c_swap*
brw-rw---- 1 root disk 252, 16 2010-01-03 19:20 /dev/mapper/c_swap
brw-rw---- 1 root disk 252, 16 2010-01-03 19:20 /dev/mapper/c_swap_unformatted

(The same behaviour is NOT observed for encrypted /tmp)

/etc# egrep swap fstab crypttab
fstab:/dev/mapper/c_swap none swap sw 0 0
crypttab:c_swap /dev/mapper/VG1-c_swap /dev/urandom size=128,swap

[Stefan Fleiter (stefan-fleiter)]

I have this problem here with Lucid as of today, too.

# ls /dev/mapper/
control home home_unformatted root var var_unformatted

According to the cryptsetup bugreport this could be caused by
udev or DeviceKit-disks.

At the moment I assume that this causes mountall not to mount my
home and var partition which means I have to manually support
every single boot process.

[Steve Langasek (vorlon)]

Stefan,

> At the moment I assume that this causes mountall not to mount my
> home and var partition which means I have to manually support
> every single boot process.

No, this issue does not cause failures in mounting the decrypted partitions. If your partitions are not being mounted correctly on boot, and if you have the current version of mountall installed (version 2.4), please file a new bug report.

[Stefan Fleiter (stefan-fleiter)]

Forgot to mention:
I opened bug 508848 for mountall not mounting the decrypted partition.

[mejo (jonas-freesources)]

I guess this bug has been identified in buglog of bug 508848, right? thus i suggest to change status to 'invalid'.

[Daniel Kauffman (sound-man-dan)]

This is a regression from bug 475936, see comment #30 there.

Running the cryptdisks_start script:

# cryptdisks_start CRYPT

In turn runs:

# dmsetup rename CRYPT_unformatted CRYPT

as a result of which the CRYPT device is created but the CRYPT_unformatted device is not removed.

I have filed bug 612310 against dmsetup, resolving that bug should resolve this as well.

[Daniel Kauffman (sound-man-dan)]

The attached forces cryptdisks_start to wait until it is safe to rename the device. In my case, the delay is typically about one second.

The attached is only a work-around, it seems to me that such logic would be better suited somewhere in dmsetup. See bug 612310 comment #2.