cryptsetup doesn't understand UUID= in crypttab

Bug #153597 reported by Kjell Braden on 2007-10-17
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Martin Pitt

Bug Description

Binary package hint: cryptsetup

Cryptsetup can't understand devices specified by UUID=... or LABEL=... (I'm not sure whether encrypted devices can actually have a label) in /etc/crypttab. The attached patch should make that work. (Note that I couldn't test the LABEL= part, since I don't have an encrypted device with a label)

I checked this on up-to-date gutsy with cryptsetup 2:1.0.5-2ubuntu2

Kjell Braden (afflux) wrote :
description: updated
Hadmut Danisch (hadmut) wrote :

Yeah, would be really nice to have cryptsetup (and especially the initramfs cryptroot script) understand UUID= and LABEL=, especially since /dev/hda devices appear as /dev/sda since gutsy. Would avoid some confusion.


Changed in cryptsetup:
assignee: nobody → warp10
status: New → In Progress
Andrea Colangelo (warp10) wrote :

I used Kjell's patch to create a debdiff. It build and install correctly.

Changed in cryptsetup:
status: In Progress → Confirmed
Changed in cryptsetup:
assignee: warp10 → nobody
Changed in cryptsetup:
importance: Undecided → Wishlist
Martin Pitt (pitti) wrote :

I don't quite understand this. I made a patch to gutsy's cryptsetup which gets along with specifying /dev/disk/by-uuid/<UUID> as the second argument in /etc/crypttab (which is the source device). What's wrong with that?

Changed in cryptsetup:
status: Confirmed → Incomplete
jcfp (jcfp) wrote :

From the technical standpoint, nothing is wrong with that. But specifying uuid via /dev/disk/by-uuid/(uuid) is:

- non-standard, as compared to /etc/fstab as well as grub's menu.lst format of using UUID=(just the uuid)
- undocumented; not mentioned in /etc/crypttab or it's man page

Martin Pitt (pitti) wrote :

Ah, I see. Well, why not. I'll apply Andrea's debdiff soon, thanks Kjell!

Changed in cryptsetup:
assignee: nobody → pitti
status: Incomplete → In Progress
Martin Pitt (pitti) wrote :

I tested the change, works fine. I'll submit that to Debian bug 445189 and upload it to Hardy. Thank you!

Andrea Colangelo (warp10) wrote :

cryptsetup (2:1.0.5-2ubuntu6) hardy; urgency=low

  * Make cryptsetup understand devices specified by UUID=... or LABEL=
    in crypttab. (LP: #153597)

 -- Andrea Colangelo <email address hidden> Mon, 29 Oct 2007 18:22:51 +0100

Changed in cryptsetup:
status: In Progress → Fix Released
Emil Sit (emilsit) wrote :

This does work for UUIDs (tested on Hardy Beta 2:1.0.5-2ubuntu9); it might be nice to also update the crypttab(5) man page and /usr/share/doc/cryptsetup/CryptoSwap.HowTo files. Incidentally, is this how the encrypted alternate installer sets up encrypted swap and other partitions?

Heiko (h-e-noordhof) wrote :

Also, it would be nice if the cryptab command itself would understand UUID=xxxx-yyy- as well..

Now, in 'heron', crypttab does support uuid's (nice!), but cryptsetup from the command line does not.

I only need/want to luksOpen/mount my backup disk and I do this from a script. Now need to find a way to determine if my back partition will be /dev/sda1 or /dev/sdb1 (at boot time it *does* happen that the disk switches for sda to sdb).

Kjell Braden (afflux) wrote :

You can work around this by just using /dev/disk/by-uuid/xxxx-yyy-

Heiko <email address hidden> writes:

> Also, it would be nice if the cryptab command itself would understand
> UUID=xxxx-yyy- as well..

please file another bug for this.

Reinhard Tartler, KeyID 945348A4

Was this issue really fixed (status is 'Fix Released')?
I'm on Ubuntu 14.04 and I'm still having the problem.

Note on Importance: I use Ubuntu on a portable USB hard drive which I can connect to any computer and boot. These computers have different disk configurations, and therefore I prefer to specify mounts by UUID rather than device filename. (For example, in one computer boot disk could be /dev/sdb and on another could be /dev/sdc). Therefore, I think UUID is important.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers