[pkg-cryptsetup-devel] Bug#807600: Bug#807600: Boot hangs

[Jonas Meurer]

Hi John,

Am 17.12.2015 um 17:02 schrieb John Talbut:
> On 17/12/15 11:22, Jonas Meurer wrote:
>>> Is there anything else I can do to help diagnose the problem?
>>
>> In the initramfs emergency shell that starts, please run the following
>> commands and send us the result:
>>
>> # ls -al /dev/mapper/
> # No such file or directory
> 
> But
> # ls /dev/mapper/
> 
> drwxr-xr-x  2 0 0     60 .
> drwxr-xr-x 13 0 0   3060 ..
> crw-------  1 0 0 10,236 control
> 
>> # dmsetup table
> # No devices found

Ok, so during initramfs stage, no device-mapper device is created until
the point that it drops into the emergency shell.

>> # sed -i -e 's#/bin/sh#/bin/sh -x#g' /scripts/local-top/cryptroot
>> # /scripts/local-top/cryptroot>
> # Syntax error: newline unexpected
> 
> but if I put a file name (on a mounted data stick) after this, the file
> contained:

The sed command is supposed to append a '-x' to the shebang (first line)
of the script /scripts/local-top/cryptroot, so that it becomes
'#!/bin/sh -x'. This enables the debug mode in the shell script.

The second command had a typo at the end: The '>' was not supposed to be
there. *If* you want to redirect output of the script to a file, you'll
need to redirect STDOUT *and* STDERR:

# /scripts/local-top/cryptroot >/mnt/initramfs_cryptroot.log 2>&1

>   Reading all physical volumes.  This may take a while...
> Begin: Waiting for encrypted source device... ...   Reading all physical
> volumes.  This may take a while...
> [...]

Unfortunately, this is only the STDOUT output of the script, without the
debug logs to STDERR. But see below.

>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
> done.
>   ALERT! /dev/disk/by-uuid/48537739-1f62-4c12-8bf1-9d662d8cc74f does not
> exist.
>     Check cryptopts=source= bootarg: cat /proc/cmdline
>     or missing modules, devices: cat /proc/modules; ls /dev
> -r Dropping to a shell. Will skip
> /dev/disk/by-uuid/48537739-1f62-4c12-8bf1-9d662d8cc74f if you can't fix.

Your sda2_crypt device is not unlocked by the cryptroot script in
initramfs stage for a simple reason: The UUID that you defined as the
UUID for the source device is not found.

Your /etc/crypttab contains the following:

sda2_crypt UUID=48537739-1f62-4c12-8bf1-9d662d8cc74f none luks

This means, that the initramfs cryptroot script will search for a device
with UUID '48537739-1f62-4c12-8bf1-9d662d8cc74f' and try to unlock it.
Obviously, that device does not exist (at least not initramfs stage).

What do the following commands in the initramfs emergency shell give:

# cat /conf/conf.d/cryptroot
# ls /dev/disk/by-uuid/
# ls /dev/sd*
# blkid /dev/sd*

My current guess is, that your problem is simply a wrong UUID defined in
crypttab. Most likely, correcting the UUID in /etc/crypttab and
recreating the initramfs afterwards will fix your issue.

Also, as a sidenode: it seems like you have the same line repeated three
times in /etc/crypttab. You can safely remove all but one.

Cheers
 jonas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20151218/93149777/attachment.sig>