Encrypted SWAP partition not created/mounted

[Ulrich Lukas]

Binary package hint: cryptsetup

Hi,

after updating to Jaunty Alpha, the setup of cryptographic swap on boot fails with the following message:

"* SWAP: the check for '/dev/mapper/SWAP' failed. /dev/mapper/SWAP contains data: - The device /dev/mapper/SWAP contains a valid filesystem type unknown or non-unique volume type (--probe-all lists possibly conflicting types)."

The same message appears when invoking as root: "/etc/init.d/cryptdisks start".

"ls /dev/mapper" shows that indeed the "SWAP" target isn't created.

This is very similar to the old, already resolved Debian-bug #385317:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385317

Manually creating a cryptographic "swap" target without using /etc/crypttab and its "swap" option works.

This is a regression.

My setup:
Kubuntu Jaunty AMD64, custom Linux 2.6.28, cryptsetup version 2:1.0.6-7ubuntu1

I'd gladly help with further debugging; please feel free to ask.

[Ulrich Lukas (ulrich-lukas)]

Content of my /etc/ctypttab:
# <target name> <source device> <key file> <options>
SWAP /dev/sde8 /dev/urandom swap

[nodemaster (mkossin)]

I have the same problem with swap and cryptsetup.

Furthermore it's the same problem with the "tmp" option. Thus I guess it's related.

root@hubble:/home# /etc/init.d/cryptdisks start
 * Starting remaining crypto disks... * tmp (starting)
 * tmp: the precheck for '/dev/mapper/sil_ajabbgcfcdah5' failed: - The device /dev/mapper/sil_ajabbgcfcdah5 contains a valid filesystem type unknown or non-unique volume type (--probe-all lists possibly conflicting types).
 * tmp (failed)... [ OK ]

/etc/crypttab:

# <target name> <source device> <key file> <options>
swap /dev/mapper/sil_ajabbgcfcdah3 /dev/urandom swap
tmp /dev/mapper/sil_ajabbgcfcdah5 /dev/urandom tmp=xfs

root@hubble:/home# fdisk -l /dev/mapper/sil_ajabbgcfcdah

Disk /dev/mapper/sil_ajabbgcfcdah: 400.0 GB, 400087408640 bytes
255 heads, 63 sectors/track, 48641 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0003cf0b

                       Device Boot Start End Blocks Id System
/dev/mapper/sil_ajabbgcfcdah1 1 122 979933+ 83 Linux
/dev/mapper/sil_ajabbgcfcdah2 123 4985 39062047+ 83 Linux
/dev/mapper/sil_ajabbgcfcdah3 4986 6230 10000462+ 83 Linux
/dev/mapper/sil_ajabbgcfcdah4 6231 48641 340666357+ 5 Extended
/dev/mapper/sil_ajabbgcfcdah5 6231 7475 10000431 83 Linux
/dev/mapper/sil_ajabbgcfcdah6 7476 48641 330665863+ 83 Linux

Setup:
- Mythbuntu Jaunty
- Linux hubble 2.6.28-4-generic #9-Ubuntu SMP Tue Jan 6 19:34:01 UTC 2009 i686 GNU/Linux
- cryptsetup 2:1.0.6-7ubuntu1

[Shiv V (svenkata)]

It seems this is due to a change in vol_id (udev package). vol_id (udev: 124-12) used to say "/dev/mapper/swap: unknown volume type" when it failed to find a known filesystem on /dev/mapper/swap. After my latest update, vol_id (udev: 136-4) says "unknown or non-unique volume type (--probe-all lists possibly conflicting types)" without mentioning the device. /lib/cryptsetup/checks/{vol_id,un_vol_id} have not been updated to check for the new vol_id output with the result that code in /lib/cryptsetup/cryptdisks.functions assumes that vol_id has found some valid filesystem when it hasn't.

Instead of hard-coding the vol_id output when no valid filesystem is found, we could determine it at run time by running vol_id on some device or file that is guaranteed to not have any filesystem. Would /dev/null work? I've attached a patch to update vol_id and un_vol_id to use the following:

# vol_id output if $dev has an unknown filesystem
pattern=`echo $dev | sed 's/\//\\\\\//g'`
unknown=`/lib/udev/vol_id -t /dev/null 2>&1 | sed "s/\/dev\/null/$pattern/g"`

if [ "$vol_id" != "$unknown" ] && [ "$vol_id" != "minix" ] && [ -z "$fs" ]; then
...

[Ulrich Lukas (ulrich-lukas)]

Many thanks for your help Shiv!

I've applied the patch to vol_id and un_vol_id in /lib/cryptsetup/checks/.

Now, the automated creation of the swap device works again.

Looking at the scripts, your explanation seems absolutely plausible to me.

I've even cross-checked the detection by trying the following once with dev="/dev/null" and dev="/dev/sda1":
> vol_id=`/lib/udev/vol_id -t $dev 2>&1`
> pattern=`echo $dev | sed 's/\//\\\\\//g'`
> unknown=`/lib/udev/vol_id -t /dev/null 2>&1 | sed "s/\/dev\/null/$pattern/g"`
> if [ "$vol_id" != "$unknown" ] && [ "$vol_id" != "minix" ] && [ -z "$fs" ]; then echo FILESYSTEM DETECTED; fi

Seems to work...

[nodemaster (mkossin)]

This patch fixes the problem with swap and tmp option.

Your help is much appreciated Shiv. Thank you very much indeed!

[Tworkemon (tworkemon)]

The patch works for non SWAP/TMP partitions also. I had the same problem with /dev/sda4 and this patch worked.

[David Tomaschik (matir)]

Same problem here. Seems like a pretty big issue.

[Ulrich Lukas (ulrich-lukas)]

Hello, maintainer...

[Dustin Kirkland  (kirkland)]

I'm getting the same issue.

I'll take a look at it.

:-Dustin

[Dustin Kirkland  (kirkland)]

Tested the patch, works here. Examined, looks good. I'm sponsoring.

In the future, please subscribe ubuntu-main-sponsors to the bug if there's a patch and you're requesting sponsorship/upload.

Thanks!
:-Dustin

[Launchpad Janitor (janitor)]

This bug was fixed in the package cryptsetup - 2:1.0.6-7ubuntu3

---------------
cryptsetup (2:1.0.6-7ubuntu3) jaunty; urgency=low

  [ https://launchpad.net/~svenkata ]
  * debian/checks/un_vol_id: dynamically build the "unknown volume type"
    string, to allow for encrypted swap, LP: #316607

 -- Dustin Kirkland <email address hidden> Thu, 12 Feb 2009 16:57:30 -0600

[Andrej Rohaŭ (arohau)]

Would you be so kind to please elaborate on why we need sed here at all?

Further looking at http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/volume_id/vol_id.c;h=3e44c3b069794b81a1e61338c98eef0fa7671bf3;hb=HEAD#l254 shows vol_id always return a static string in this case, as well as error status 4.

# /lib/udev/vol_id --type /dev/null 2>&1
unknown or non-unique volume type (--probe-all lists possibly conflicting types)
# echo $?
4

Even if we want to keep it 'dynamic' for unknown string, why not keep it simple then?

@@ -25,2 +25 @@
-pattern=`echo $dev | sed 's/\//\\\\\//g'`
-unknown=`/lib/udev/vol_id -t /dev/null 2>&1 | sed "s/\/dev\/null/$pattern/g"`
+unknown=`/lib/udev/vol_id -t /dev/null 2>&1`

Thanks for looking into this!

[Dustin Kirkland  (kirkland)]

Hi Andrei-

Good catch.

I have confirmed that, in fact:
  unknown=`/lib/udev/vol_id -t /dev/null 2>&1`
returns a static string.

This is far simpler/cleaner. That super-escaped sed is truly nasty.

Let me prepare and test another upload...

:-Dustin

[Shiv V (svenkata)]

The sed part isn't necessary. I only put it in for the sake of robustness against future updates/regressions to vol_id. In the past, 'vol_id -t /dev/null' used to report "/dev/null: unknown volume type". Now it does not mention the device that was probed, just the result "unknown or non-unique volume type (--probe-all lists possibly conflicting types)".

[Shiv V (svenkata)]

Also, when I checked the vol_id source, error code 4 was not restricted to the "unknown device type" case. I can't remember of the top of my head what the other cases were that also returned error 4, but as of a month ago, there were some.

[Andrej Rohaŭ (arohau)]

Probably udev vol_id interface does not change that often for us to try to work around it in advance. Unnecessary calls from startup scripts is a plague that slows whole system boot process. Checking shell error codes would be the fastest and cleanest of all, but unfortunately vol_id shares error code 4 for both unknown filesystem and various probing errors.

And in the case of http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/volume_id/vol_id.c;h=3e44c3b069794b81a1e61338c98eef0fa7671bf3;hb=HEAD#l308 it does look like a typo to me, as the whole switch statement introduces error code 3 for raid checks.

[Andrej Rohaŭ (arohau)]

Any update on the sed issue? 2:1.0.6-7ubuntu6 still contains it.