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
signature.asc
Description: OpenPGP digital signature
