UUID= syntax not recognized by cryptsetup in initrd LUKSDEV

johnbristol · 03-17-2012, 08:42 AM

slackware-13.37.

What I'm trying to do is create a USB flash drive which can boot regardless of the drive letter it's assigned.

The tty copy below shows that during a boot, cryptsetup isLuks says yes to "cryptsetup isLuks /dev/sdb3" but the same test fails if UUID= syntax is used.

/ # cryptsetup isLuks UUID="fa649b04-5ede-496f-9168-331161a2b833"
Device UUID=fa649b04-5ede-496f-9168-331161a2b833 doesn't exist or access denied

but that's the right UUID for the same /dev/sdb3. I can't use /dev/disk/by-uuid/foo because there's no /dev/disk at that stage of the boot.

Changing the mkinitrd -C from UUID=foo to /dev/sdb3 gives me a working boot stick but only if the drive's /dev/sdb.

I upgraded my 13.37 cryptsetup on the stick from 1.2.0 to 1.4.1 but that didn't change anything.

Is there a module I need to load to enable that syntax recognition, perhaps?

tty log:

Code:

[    6.724952]  sdb: sdb1 sdb2 sdb3
[    6.727918] sd 6:0:0:0 [sdb] Assuming drive cache: write through
[    6.729488] sd 6:0:0:0 [sdb] Attaching SCSI removable disk
/boot/initrd.gz:  Loading 'uk' keyboard mapping:
>>> Using LUKS key file: 'LABEL=xfer:/originalpassword.luks'
  No volume groups found
  LUKS device 'UUID=fa649b04-5ede-496f-9168-331161a2b833' unavailable for unlocking!
  mount: mounting /dev/fdv/root on /mnt failed: No such file or directory
  ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead.
          You can try to fix it. Type 'exit' when things are done.
 
/bin/sh: can't access tty; job control turned off
/ # blkid
/dev/sdb3: UUID="fa649b04-5ede-496f-9168-331161a2b833"
/dev/sdb2: LABEL="boot" UUID="895e3a22-1513-4fda-b7b4-5e2b67b8cac2" 
/dev/sdb1: LABEL="xfer" UUID="A5FD-1205"
/dev/sda1: UUID="358ea3e5-36cc-4db2-8894-94a84f281b8c" 
/ # cryptsetup isLuks /dev/sdb3
/ # cryptsetup isLuks UUID="fa649b04-5ede-496f-9168-331161a2b833" 
Device UUID=fa649b04-5ede-496f-9168-331161a2b833 doesn't exist or access denied
/ # cryptsetup isLuks /dev/disk/bu-uuid/fa649b04-5ede-496f-9168-331161a2b833
Device /dev/disk/bu-uuid/fa649b04-5ede-496f-9168-331161a2b833 doesn't exist or access denied

johnbristol · 03-17-2012, 10:07 AM

http://pastebin.com/vKzYGbHL is a script to create the bootable stick, as far as I've got it. It's been working fine to create a stick that will come up if it's allocated /dev/sdb, or one that will come up if it's allocated /dev/sdc, but the right answer is to eliminate the drive letters and recognize the drive directly. I'm going to have to auto-edit /etc/fstab as well, when I get that far.

I have it in mind that I'm moving a step beyond people showing each other their desktop as a graphic, toward giving each other a full installation. And it makes a pretty good hot backup too.

As for fixing my problem, I've read http://www.bluelife.at/blog/articles..._on_USB_Stick/ twice and I expect it's the way to do it but I've not understood what I've read so far. I'll try again.

johnbristol · 03-17-2012, 03:10 PM

From reading the blog I referenced earlier, I think the init script in mkinitrd needs to treat LUKSDEV the same as ROOTDEV's treated here:

Code:

    luksdev=/dev/*)
      LUKSDEV=$(echo $ARG | cut -f2 -d=)
    ;;

    root=/dev/*)
      ROOTDEV=$(echo $ARG | cut -f2 -d=)
    ;;
    root=LABEL=*)
      ROOTDEV=$(echo $ARG | cut -f2- -d=)
    ;;
    root=UUID=*)
      ROOTDEV=$(echo $ARG | cut -f2- -d=)
    ;;

and to use blkid -U to convert UUID= to /dev/sdxx for each LUKSDEV here, so that the /dev/sdxx format is either used here or in the deferred bit later.

Code:

    LUKSLIST_DEFERRED=""
    LUKSLIST=$(echo $LUKSDEV | tr -s ':' ' ')
    for LUKSDEV in $LUKSLIST ; do

I've not looked at the /etc/rc.d/rc.6 script yet, I'm feeling uncomfortably out of my depth at the moment.

elfenlied · 03-20-2012, 12:55 AM

What does your fstab look like? Also is your luks encrypted disk showing up in /dev/mapper?

I have been playing around with luks encrypted volumes today and this is what my /etc/fstab looks like, mind you I'm using centos.

Code:

#
# /etc/fstab
# Created by anaconda on Fri Mar  2 22:01:06 2012
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=4b93c7d4-6c92-494e-a076-4c897b3df7b5 /                       ext4    defaults        1 1
UUID=3159a2d8-7efd-469b-a196-dd6477ba816e /boot                   ext4    defaults        1 2
UUID=8f944bbb-37e1-4a03-a7fc-8e73faca25a3 /home                   ext4    defaults        1 2
UUID=30c6ddb4-47d4-4f0f-be97-04bf380f52dc swap                    swap    defaults        0 0
UUID=9b06c71e-3dda-4223-a729-0c24db4bdda0 /mnt/crypt		  ext4	  defaults	  1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

So from that I'm not hard coding any device names so I am going to assume that it will work regardless of what the system decides the device names for those drives will be, I could probably test it on a usb key tonight to verify.

Also on centos my /etc/crypttab looks like this:

Code:

mntcrypt /dev/disk/by-uuid/bf2e807f-fe92-461b-9cde-a19fdd38e034 none

I think I might have the same issue you're having with the crypttab but I'll see if I can setup a test install on a USB key and verify.

johnbristol · 03-20-2012, 12:39 PM

I ought to have looked before I wrote that about fstab - you're quite right, it has no specific references:

Code:

/dev/jhv/swap    swap             swap        defaults         0   0
/dev/jhv/root    /                ext4        defaults         1   1
/dev/jhv/home    /home            ext4        defaults         1   2
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0

Slackware gets by without a /etc/crypttab. The issue I'm patching is way back in the bootstrap process where the initrd is at work. Cryptsetup doesn't know UUID= and udev hasn't started so there's no /dev/disk/ so the only way is to put something like a blkid call before the cryptsetup stage to feed it the runtime /dev/sdxx for whatever LVM volumes need opening.

When I've got it tested I'll add it to the thread, there's been days with no spare hours since I started it.

elfenlied · 03-20-2012, 05:10 PM

What do they do with Slax? You might be able to do something similar as they do there?

johnbristol · 03-22-2012, 12:12 PM

It takes a while to find sufficient time to check but I now reckon this works. I can boot my USB stick whether it's /dev/sdb or /dev/sdc and the distinction is made at boot time.

13.37 Slackware /boot/initrd-tree/init

Code:

bash-4.1# cat init.diff
98a99,101
>     luksdev=UUID=*)
>       LUKSDEV=$(echo $ARG | cut -f2- -d=)
>     ;;
203a207,209
>       if echo $LUKSDEV | grep -q "UUID=" ; then
>         LUKSDEV=$(blkid | grep ${LUKSDEV:5} | awk -F':' '{print $1 }')
>       fi
bash-4.1# 

lvmdev=`blkid | grep sd$13 | awk -F'"' '{print $2 }'`
mkinitrd -c -k 2.6.37.6-smp -m ext4 twofish -f ext4 -r /dev/fdv/root -C UUID="$lvmdev" -l uk -L -K LABEL=xfer:/originalpassword.luks -w 5

My lilo.conf has boot=/dev/sdb which is the correct reference to the MBR at the time lilo is run, it has no impact at boot time. My /etc/fstab has no "/dev/sdx"-specific entries.

I note that alienBOB's existing slackware-13.37/README_CRYPT.TXT already allows the main drive to have just one LVM partition on it and nothing else, and to put /boot and (on a vfat partition) the --key-file onto a USB flash drive which can be inserted just to boot and removed before logging in. That's how I'd been running my laptop. This change to /boot/initrd-tree/init now lets me carry a bootable USB flash drive with the LVM partition on it as well, and use it on a range of host PCs.

Alien Bob · 03-23-2012, 07:18 AM

Quote:

Originally Posted by johnbristol

It takes a while to find sufficient time to check but I now reckon this works. I can boot my USB stick whether it's /dev/sdb or /dev/sdc and the distinction is made at boot time.

13.37 Slackware /boot/initrd-tree/init

Code:

bash-4.1# cat init.diff
98a99,101
>     luksdev=UUID=*)
>       LUKSDEV=$(echo $ARG | cut -f2- -d=)
>     ;;
203a207,209
>       if echo $LUKSDEV | grep -q "UUID=" ; then
>         LUKSDEV=$(blkid | grep ${LUKSDEV:5} | awk -F':' '{print $1 }')
>       fi
bash-4.1# 

lvmdev=`blkid | grep sd$13 | awk -F'"' '{print $2 }'`
mkinitrd -c -k 2.6.37.6-smp -m ext4 twofish -f ext4 -r /dev/fdv/root -C UUID="$lvmdev" -l uk -L -K LABEL=xfer:/originalpassword.luks -w 5

My lilo.conf has boot=/dev/sdb which is the correct reference to the MBR at the time lilo is run, it has no impact at boot time. My /etc/fstab has no "/dev/sdx"-specific entries.

I note that alienBOB's existing slackware-13.37/README_CRYPT.TXT already allows the main drive to have just one LVM partition on it and nothing else, and to put /boot and (on a vfat partition) the --key-file onto a USB flash drive which can be inserted just to boot and removed before logging in. That's how I'd been running my laptop. This change to /boot/initrd-tree/init now lets me carry a bootable USB flash drive with the LVM partition on it as well, and use it on a range of host PCs.

Perhaps this diff is a bit cleaner, but I agree that this is a good enhancement for the init script:

Code:

98a99,101
>     luksdev=UUID=*)
>       LUKSDEV=$(echo $ARG | cut -f2- -d=)
>     ;;
203a207,209
>       if echo $LUKSDEV | grep -q "UUID=" ; then
>         LUKSDEV=$(findfs $LUKSDEV)
>       fi

Eric

GazL · 03-23-2012, 10:26 AM

Adding UUID support to LUKSDEV is definitely a nice idea, but it's not quite as simple as the above.

Since the additon of support for the unlocking of multiple luks devices in the initrd LUKSDEV is now a colon delimited list of devices to be unlocked (though most people don't use this feature).. We need to allow for:
luksdev=UUID=wibble-wibble-wibble:UUID=wobble-wobble-wobble.
or
luksdev=/dev/sda3:UUID=wibble-wibble-wibble
...and so on.

Also in theory some of these may not be available for findfs to find in the first pass such as LVM LVs that won't become visible until after the vgscan
(that's what the deferred bit is all about), so we need a little extra logic..

I've not tested this, and it's only the work of a few minutes so treat with caution but I think it'll be about right.:

Code:

gazl@slackbox:/tmp/mkinitrd$ diff -u init.orig init
--- init.orig   2011-03-21 23:04:24.000000000 +0000
+++ init        2012-03-23 15:07:33.850345426 +0000
@@ -93,7 +93,7 @@
     init=*)
       INIT=$(echo $ARG | cut -f2 -d=)
     ;;
-    luksdev=/dev/*)
+    luksdev=*)
       LUKSDEV=$(echo $ARG | cut -f2- -d=)
     ;;
     lukskey=*)
@@ -201,6 +201,11 @@
     LUKSLIST_DEFERRED=""
     LUKSLIST=$(echo $LUKSDEV | tr -s ':' ' ')
     for LUKSDEV in $LUKSLIST ; do
+      if echo $LUKSDEV | grep -q "UUID=" ; then
+        if LUKSTMP=$(findfs $LUKSDEV) ; then
+           LUKSDEV="$LUKSTMP"
+        fi
+      fi
       if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
         if echo $ROOTDEV | grep -q "LABEL=" || echo $ROOTDEV | grep -q "UUID=" ; then
           CRYPTDEV="luks$(basename $LUKSDEV)"
@@ -230,6 +235,11 @@
 
   if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}" ]; then
     for LUKSDEV in ${LUKSLIST_DEFERRED} ; do
+      if echo $LUKSDEV | grep -q "UUID=" ; then
+        if LUKSTMP=$(findfs $LUKSDEV) ; then
+           LUKSDEV="$LUKSTMP"
+        fi
+      fi
       if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
         if echo $ROOTDEV | grep -q "LABEL=" || echo $ROOTDEV | grep -q "UUID=" ; then
           CRYPTDEV="luks$(basename $LUKSDEV)"

johnbristol · 03-23-2012, 06:01 PM

I'm surprised, I thought the line

Code:

for LUKSDEV in $LUKSLIST ; do

broke the colon-delimited list into single entries each of which might be /dev/sdxn or UUID=foo, and that each was treated individually thereafter.

GazL · 03-24-2012, 03:47 AM

You're right John, it does, but I was referring to that first hunk in the patch outside of the for-loop which wouldn't have behaved correctly to a luksdev parameter such as
luksdev=/dev/sda1:UUID=123-456-789 because it wouldn't have matched the "luksdev=UUID=*" pattern in the 'case' statement. Although that is probably somewhat of a corner case, it's wise to try and cover all the bases.

johnbristol · 03-24-2012, 04:23 PM

Either case matching selects the whole single string for processing, whether the /dev or the /UUID comes first in the list.

eta: I'm sorry,that sounded like point-scoring and it's not meant to be, that's how I discuss code at reviews whether it's mine or someone else's. I'm grateful for the analysis.

GazL · 03-24-2012, 05:05 PM

Quote:

Originally Posted by johnbristol

Either case matching selects the whole single string for processing, whether the /dev or the /UUID comes first in the list.

eta: I'm sorry,that sounded like point-scoring and it's not meant to be, that's how I discuss code at reviews whether it's mine or someone else's. I'm grateful for the analysis.

Ahh yes, fair point I was forgetting that the existing luksdev=/dev/*) would have matched that example. I still believe that replacing both those case matches with a single entry is the correct thing to do considering they both do exactly the same thing on a match, but clearly my reasoning was off.

And don't worry. I didn't take it as point-scoring. If I've missed something I'd rather people tell me. Thanks for pointing it out.