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
There is no action possible in the bcache-tools package so I'm marking
that task as Invalid - but the cryptsetup task remains open.
** Changed in: bcache-tools (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
It may be that cryptsetup needs to be taught to use offset= and skip=
for LUKS as well as plain.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810235
Title:
cryptsetup silently fails in live
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
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
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
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
Additional Information:
gdisk shows the partition type as , 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
