# Automounting luks USB drive on boot

## mantonson

I have a machine at a remote location that has a USB hard drive, encrypted with luks.  Only the USB drive is encrypted, root is not (I backup sensitive data remotely to this USB drive).  root is /dev/sda, USB is /dev/sdb.  I had it setup to automount on system boot, and everything was working fine.  Then I switched to the 17.0 profile and rebuilt world, and now it will no longer automount.

I'm using dm-crypt at the boot runlevel to open the luks container, here's my /etc/conf.d/dmcrypt file:

```
target=crypt-sdb1

#source=UUID="ca072fd9-580b-4a82-873e-28ec85378d4a"

source='/dev/sdb1'

key='/etc/keys/enc.key'
```

And here's my /etc/fstab:

```
#/dev/mapper/crypt-sdb1  /mnt/backup     jfs             nofail,noatime  0 2

UUID="96179ce6-304b-468c-97cd-50dbfc6b0665" /mnt/backup jfs nofail,noatime 0 2
```

Everything is working fine except automounting - if I manually open it using luksOpen, and mount it, all data is there.  You can see I tried switching to UUIDs, but no difference. I turned on rc logging, and this is what I see for boot runlevel:

```
rc boot logging started at Fri Jan 12 19:02:53 2018

 * Setting system clock using the hardware clock [UTC] ...

 [ ok ]

 * Setting up dm-crypt mappings ...

 * source "/dev/sdb1" for crypt-sdb1 missing, skipping...

 [ ok ]

 * Checking local filesystems  ...

fsck.jfs version 1.1.15, 04-Mar-2011

processing started: 1/12/2018 19:02:56

The current device is:  /dev/sda3

Block size in bytes:  4096

Filesystem size in blocks:  28783990

**Phase 0 - Replay Journal Log

Filesystem is clean.

/dev/sda1: clean, 362/32768 files, 49382/131072 blocks

 [ ok ]

 * Remounting root filesystem read/write ...

 [ ok ]

 * Remounting filesystems ...

 [ ok ]

 * Updating /etc/mtab ...

 * Creating mtab symbolic link

 [ ok ]

 * Activating swap devices ...

 [ ok ]

 * Mounting local filesystems ...

 [ ok ]

 * Mounting misc binary format filesystem ...

 [ ok ]

 * Loading custom binary format handlers ...

 [ ok ]

 * Configuring kernel parameters ...

 [ ok ]

 * Creating user login records ...

 [ ok ]

 * Wiping /tmp directory ...

 [ ok ]

 * Setting hostname to trinity  ...

 [ ok ]

 * Setting terminal encoding [UTF-8] ...

 [ ok ]

 * Setting keyboard mode [UTF-8] ...

 [ ok ]

 * Loading key mappings [us] ...

 [ ok ]

 * Bringing up network interface lo ...

 [ ok ]

 * Setting up tmpfiles.d entries ...

 [ ok ]

 * Initializing random number generator ...

 [ ok ]

rc boot logging stopped at Fri Jan 12 19:02:58 2018
```

So it seems that dmcrypt is being started before /dev/sdb1 is showing up?  Here's the output from rc-status boot:

```
Runlevel: boot

 modules                                                           [  started  ]

 hwclock                                                           [  started  ]

 dmcrypt                                                           [  started  ]

 fsck                                                              [  started  ]

 root                                                              [  started  ]

 mtab                                                              [  started  ]

 swap                                                              [  started  ]

 localmount                                                        [  started  ]

 procfs                                                            [  started  ]

 binfmt                                                            [  started  ]

 sysctl                                                            [  started  ]

 bootmisc                                                          [  started  ]

 hostname                                                          [  started  ]

 termencoding                                                      [  started  ]

 keymaps                                                           [  started  ]

 loopback                                                          [  started  ]

 opentmpfiles-setup                                                [  started  ]

 urandom                                                           [  started  ]
```

What I don't know is, what do I need to adjust so dmcrypt won't start until after the USB hard drive is available?

----------

## eccerr0r

Did you recompile your kernel and your USB driver(s) are modules now, causing a race condition?

Since your USB drive is not a root disk, is it a problem to run dm-crypt later on, say, at the default runlevel instead of boot?

----------

## mantonson

I did move up kernels (4.4.6 to 4.9.72) but all I did was make olddefconfig, nothing changed from previous config.

I could move it runlevels, but then it wouldn’t be ready to mount via fstab I believe.

----------

## mantonson

I tried a couple promising kernel boot parameters I found here: https://wiki.gentoo.org/wiki/Handbook:AMD64/Blocks/Booting, namely slowusb and scandelay, but since it's a remote machine I have no idea if they actually took affect (/proc/cmdline shows they were executed).  Regardless, they didn't fix the problem.

I'm agreeing, it seems like some sort of timing issue, like udev isn't enumerating /dev/sdb until too late in the process. I did note that /var/log/dmesg doesn't show /dev/sdb until almost the last entry.

----------

## mantonson

Interesting - tried going back to my 4.4.6 kernel image, and it maps fine.  So it does seem to be related to my new kernel.  I'll go recopy my 4.4.6 config file, then try make silentoldconfig instead of make olddefconfig, and see if there are any important new options.

----------

## mantonson

OK, so it's definitely related to the new kernel I built.  But going through the new options using make silentoldconfig, I didn't see anything obvious.  At this point I'm assuming it's not an option as much as just a difference in behavior.  Any suggestions?

----------

