cryptsetup silently fails in live environment when given a raw "bcached" block device

[dundir]

When attempting to acccess an existing (working) LUKS partition from the LiveCD environment, cryptsetup fails silently. No exceptions are thrown, no errors displayed. The LUKS device remains completely inaccessible.

I've attached an strace with the following two commands, "cryptsetup luksDump /dev/sda3", and "cryptsetup luksOpen /dev/sda3 crypted" as there was nothing in the logs that clearly point to a problem other than the expected result being missing.

lsb-release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"

    #uname -a
Linux ubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: cryptsetup 2:2.0.2-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CasperVersion: 1.394
Date: Wed Jan 2 03:56:27 2019
LiveMediaBuild: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash ---
crypttab: # <target name> <source device> <key file> <options>
fstab:
 overlay / overlay rw 0 0
 tmpfs /tmp tmpfs nosuid,nodev 0 0

[dundir (dundir)]

Additional Information:

gdisk shows the partition type as FFFF, the drive (sda3) boots and runs without issue. Cryptsetup however; cannot access it after boot but it does properly mount and run the contents of the encrypted partition (i.e. root drive).

The drive was originally set up following the instructions found at the link below with the intention being to resize the encrypted portion later (expand) via a livecd.

https://askubuntu.com/questions/620480/how-to-install-ubuntu-with-both-disk-encryption-and-ssd-caching

[dundir (dundir)]

Following up and to clarify my initial post a bit, I've found the main issue is with cryptsetup (or related system) expecting LUKS to be located within a certain boundary and bcache creates an offset on the backing drive that shifts this boundary outside where cryptsetup looks. The package should throw an exception or at the least say it didn't find the partition but it fails silently and that will require further investigation.

There is other strange behaviour when working with bcache created partitions where bcache backed drives have been created but are then accessed from another computer (where bcache-tools have not been installed). These include some utilities throwing errors that the device partition doesn't exist (when it clearly does) and the silent fail with cryptsetup and devicemapper.

The drive can become accessible by mounting these systems using a loopback offset such as the command below.
losetup -o 8192 /dev/loop8 /dev/sda3 will correct many of these problems.

[Andreas Hasenack (ahasenack)]

Could this be solved with different ordering? Luks first, then bcache? Luks definitely expects its header to be in a certain position:

LUKS EXTENSION
       LUKS, the Linux Unified Key Setup, is a standard for disk encryption. It adds a standardized header at the start of the device, a key-slot area directly behind the header and the bulk data area behind that. The
       whole set is called a 'LUKS container'. The device that a LUKS container resides on is called a 'LUKS device'. For most purposes, both terms can be used interchangeably. But note that when the LUKS header is at
       a nonzero offset in a device, then the device is not a LUKS device anymore, but has a LUKS container stored in it at an offset.

[dundir (dundir)]

Possibly, if there is a way to ensure bcache only caches encrypted block data and not the cleartext blocks.

There may be a way of setting the backing drive to work with a different ordering but I'll need to run some tests and I'm not the most knowledgeable in regards to bcache, its been a learning experience. I'll play with it when I have some free time to see if I can make it work. I'll post back here with the results.

[TJ (tj)]

It may be that cryptsetup needs to be taught to use offset= and skip= for LUKS as well as plain.

[Robie Basak (racb)]

I hope my change of bug title clarifies the edge case when this bug occurs. If I have misunderstood I'd appreciate being corrected.

Because this is a pretty uncommon use case, I'm marking the bug importance as Low. Volunteers welcome - though I suspect that any volunteering would best be done upstream.

[Robie Basak (racb)]

There is no action possible in the bcache-tools package so I'm marking that task as Invalid - but the cryptsetup task remains open.