cryptsetup does not understand UUID= in fstab and conf.d/resume

In /etc/fstab you must use /dev/mapper/<name> entries, because this is what you mount. Afaik the UUID= entries placed in /etc/crypttab should work, as should LABEL= entries and also direct /dev/XdaY.

Did you misunderstand how it all works or is it still a bug? If so, then include all configuration files: /etc/crypttab, conf/conf.d/cryptroot, kernel parameters and altough this have nothing to do with cryptsetup also fstab and conf.d/resume.

Since the fstab manpage documents the UUID syntax, how do you justify your claim that "in /etc/fstab you must use /dev/mapper/<name> entries"?

Actually, it seems to me that you misunderstood the point of the bugreport. This bug is about cryptsetup, since cryptsetup is the application that fails to parse a valid /etc/fstab.

To reproduce the problem, set up a system with encrypted root and encrypted swap and use the LABEL= or UUID= syntax in /etc/fstab and /etc/initramfs-tools/conf.d/resume. Your system will not boot.

Then try the same without using encryption. The system will boot fine.

I can confirm this bug on Ubuntu 8.10. Nikolaus is correct. Not only may UUIDs be used to reference LVM volumes in /etc/fstab, this is the default configuration in 8.10. I followed the instructions here (https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto) in order to create a LUKS+LVM encrypted system with AES-XTS, which as of this time is currently unsupported by the alternative installer.

After manually creating a LUKS volume, setting up the LVM, and creating the partitions using the 8.10 Live CD, I installed as normal. The installer setup the system as if it was an unencrypted LVM volume. The LVM volumes in /etc/fstab were referenced by their UUID. However, I found that with this setup the system is unbootable, and no warning is displayed when the initrd is created. There simply is no config/config.d/cryptroot and thus the system is unbootable.

Modifying /etc/fstab to reference the device name resolves the issue. However, UUIDs may be used in /etc/crypttab.

My understanding from reading some other bug reports is that the UUID is inaccessible because it's only available when the volume has been decrypted. However, aren't the partitions mounted by the time fstab is read to mount them? I would assume /etc/crypttab is read first to decrypt the LUKS volume, and then the UUID of the LVM volumes should be accessible to the system. Perhaps I'm wrong about this.

Anyway, this is a serious issue as it causes the system to become unbootable with no warning.

That should read - "isn't the partition decrypted by the time fstab is read to mount the LVM volumes?"

The problem is not the accessibility of the UUID. All UUIDS (encrypted or not) are available when the initramdisk is created, and that is the point that is currently broken.

Confirmed and still affecting Jaunty.

The root-cause is /usr/share/initramfs-tools/hooks/cryptroot (debian/initramfs/cryptroot-hook in the source package).

The script is called when update-initramfs is executed. It is responsible for correlating /etc/fstab entries with those in /etc/crypttab and then configuring the cryptsetup related parts of the initrd image - such as writing the keyfile name and installing any custom keyscript.

/etc/fstab is searched for the / (root) entry. The add_device() function then tries to canonicalise the name in canonical_device(). Although the function correctly canonicalises LABEL= and UUID= it *does not* return a success result. The only name format that will do that is a name prefixed "/dev/mapper/"

When that fails there is no processing of the crypttab entry and therefore nothing is done to the initrd image.

The solution is two-stage:

1. Add additional returns to the function when LABEL or UUID match
2. In /etc/crypttab, as the target name use the LABEL or UUID itself

The result is that add_device can then correlate the UUID of the unlocked file-system in fstab with the containing device's LABEL or UUID in crypttab. My only concern right now is whether the dereferencing of symbolic links that comes after those checks ought now to be moved to the head of the function.

Here's an example:

== /etc/fstab: ==
# / was on /dev/mapper/root during installation
UUID=c5321f6e-05c0-43a7-8757-03aa29c44b04 / ext4 relatime,errors=remount-ro 0 1

== /etc/crypttab: ==
c5321f6e-05c0-43a7-8757-03aa29c44b04 /dev/disk/by-uuid/ae87e7a1-b65b-4586-9e0a-bfc6d60cebc9 /home/tj/Media/theme-song.mp3 luks,keyscript=/usr/local/sbin/crypto-usb-key.sh

The patch required is:

diff -Nu a/usr/share/initramfs-tools/hooks/cryptroot b/usr/share/initramfs-tools/hooks/cryptroot
--- a/usr/share/initramfs-tools/hooks/cryptroot 2009-02-08 02:09:53.571999044 +0000
+++ b/usr/share/initramfs-tools/hooks/cryptroot 2009-02-08 03:55:47.801000016 +0000
@@ -285,12 +285,14 @@

  altdev="${dev#LABEL=}"
  if [ "$altdev" != "$dev" ]; then
- dev="/dev/disk/by-label/$altdev"
+ echo "$altdev"
+ return 0
  fi

  altdev="${dev#UUID=}"
  if [ "$altdev" != "$dev" ]; then
- dev="/dev/disk/by-uuid/$altdev"
+ echo "$altdev"
+ return 0
  fi

  if [ -h "$dev" ]; then

My previous suggested patch would cause unwanted side effects when device aliases/symlinks are used for non-crypt disks.

This patch should provide the desired result without causing a regression:

diff -Nu cryptsetup-1.0.6/debian/initramfs/cryptroot-hook /target/usr/share/initramfs-tools/hooks/cryptroot
--- cryptsetup-1.0.6/debian/initramfs/cryptroot-hook 2009-02-09 18:42:15.358063612 +0000
+++ /target/usr/share/initramfs-tools/hooks/cryptroot 2009-02-09 18:37:40.766072461 +0000
@@ -301,6 +301,11 @@
  if [ "$altdev" != "$dev" ]; then
   echo "$altdev"
   return 0
+ elif [ "x${dev%/dev/disk/by-*/*}" = "x" ]; then
+ # support crypttab UUID/LABEL entries
+ # this is a /dev/disk/by-*/ path so return just the 'basename'
+ echo "${dev##/dev/disk/by*/}"
+ return 0
  fi

  return 1

Ooops! The patch in comment #7 was premature. This is how it should be:

diff -Nu cryptsetup-1.0.6/debian/initramfs/cryptroot-hook /target/usr/share/initramfs-tools/hooks/cryptroot
--- cryptsetup-1.0.6/debian/initramfs/cryptroot-hook 2009-02-09 18:42:15.358063612 +0000
+++ /target/usr/share/initramfs-tools/hooks/cryptroot 2009-02-09 19:00:52.954064916 +0000
@@ -293,6 +293,7 @@
   dev="/dev/disk/by-uuid/$altdev"
  fi

+ original=$dev
  if [ -h "$dev" ]; then
   dev=$(readlink -e "$dev")
  fi
@@ -301,6 +302,11 @@
  if [ "$altdev" != "$dev" ]; then
   echo "$altdev"
   return 0
+ elif [ "x${original%/dev/disk/by-*/*}" = "x" ]; then
+ # support crypttab UUID/LABEL entries
+ # this is a /dev/disk/by-*/ path so return just the 'basename'
+ echo "${original##/dev/disk/by*/}"
+ return 0
  fi

  return 1

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

  * debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
    between fstab and crypttab (LP: #287879).

 -- TJ <email address hidden> Thu, 12 Feb 2009 16:45:00 +0000

Updated the debdiff to be based off 7ubuntu3:

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

  * debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
    between fstab and crypttab (LP: #287879).

 -- TJ <email address hidden> Thu, 12 Feb 2009 16:45:00 +0000

Updated the debdiff to be based off 7ubuntu4:

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

  * debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
    between fstab and crypttab (LP: #287879).

 -- TJ <email address hidden> Mon, 16 Feb 2009 23:00:00 +0000

I adjusted your patch slightly to declare "original" as a local variable, and to use "by-*" instead of "by*" in the latter check, just to match to if clause directly. Thanks!

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

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

  * debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
    between fstab and crypttab (LP: #287879).

 -- TJ <email address hidden> Mon, 16 Feb 2009 23:00:00 +0000

Thanks Kees - you have no idea of the frustration each time I had to recover from a live-CD after the cryptsetup package updated without my realising and regenerated an initrd image without the keyscript included!

Hi - I am trying to determine if this issue applies to me. Is this the right place to ask some questions? (newbie)

My system:
$ uname -a: Linux 2.6.27-7-generic #1 SMP x86_64 GNU/Linux
$ dpkg -s cryptsetup
Package: cryptsetup
Status: install ok installed
Architecture: amd64
Version: 2:1.0.6-6ubuntu2.2

I'm guessing I either need the patch or a backport. If I need to use the patch, how would I do so?

I just installed Ubuntu on this server. I have not had problems from package updates yet. I'm guessing I will if I don't use the patch...

At the moment, I am using /dev/disk/by-uuid/ in both fstab and crypttab. It is working.

However, I would like to switch all volume references to labels. Will that present any problems? Thanks.

 cryptsetup (2:1.0.7~rc1-1) unstable; urgency=low

   * new upstream release candidate, highlights include:
     - use better error messages if device doesn't exist or is already used by
       other mapping (closes: #492926)
     - check device size when loading LUKS header
     - add some error hint if dm-crypt mapping failed (key size and kernel
       version check for XTS and LRW mode for now) (closes: #494584)
     - display device name when asking for password
     - retain readahead of underlying device, if devmapper version supports it
     - set UUID in device-mapper for LUKS devices
     - define device-mapper crypt UUID maximal length and check for its size
     - add some checks for error codes, fixes warning: ignoring return value...
     - update LUKS homepage in manpage to code.google.com/p/cryptsetup
   * patches/01_fix_make_distclean.patch: removed, incorporated upstream
   * patches/02_manpage.patch: updated, mostly incorporated upstream
   * remove invokation of ./setup-gettext.sh from debian/rules.
   * set $PATH in checks/xfs. Required to make /usr/sbin/xfs_admin work at early
     boot stage. Thanks to Stefan Bender. (closes: #525118)
   * update path to docbook-xsl stylesheet in debian/rules to
     /usr/share/xml/docbook/stylesheet/docbook-xsl/. Add versioned build-depends
     to docbook-xsl (>= 1.74.3+dfsg) for that reason.
   * fix bashisms in scripts/decrypt_opensc, thanks to Raphael Geissert.
     (closes: #530060)
   * fix UUID and LABEL handling for cryptroot, thanks to Kees Cook and ubuntu.
     (closes: #522041)
   * add ROOT=$NEWROOT to /conf/param.conf in cryptroot initramfs script. This
     is required for lilo to find the correct root device. Thanks to Pyotr
     Berezhkov and Christian Schaarschmidt. (closes: #511447, #511840)
   * replace mini autogen.sh with autoreconf in debian/rules. Thanks to Bastian
     Kleineidam. (closes: #522798)
   * support escaped newlines in askpass.c, thanks to Kees Cook and ubuntu.
     (closes: #528133)
   * use the same passphrase prompt in init script and initramfs script
   * mention the incoherent behaviour of cryptsetup create/luksOpen with invalid
     passwords/keys in cryptsetup manpage. (closes: #529359)
   * bump standards-version to 3.8.2, no changes required.
   * add 'X-Interactive: true' LSB-header to initscripts.
   * fix bash_completion script to use 'command ls'. that way it now works with
     aliased ls as well. thanks to Daniel Dehennin. (closes: #535351)

 -- Jonas Meurer <email address hidden> Sat, 04 Jul 2009 15:52:06 +0200

Even though this seems to be fixed, I'm still seeing UUID= mountpoints failing in Ubuntu 14.04.03 when that mountpoint is on a LVM logical volume. Switch fstab to use /dev/mapper/a-b syntax, initramfs gets generated with cryptsetup et al. included.

On Fri, Feb 12, 2016 at 10:45:17PM -0000, Andri Möll wrote:
> Even though this seems to be fixed, I'm still seeing UUID= mountpoints
> failing in Ubuntu 14.04.03 when that mountpoint is on a LVM logical
> volume.

Use of UUID= for LVM volumes is unsupported because a UUID is not guaranteed
to be a unique identifier in the face of snapshotting. Use the devmapper
path instead.