August 13, 2017 4:44 PM, "Coly Li" <colyli@xxxxxxx> wrote: Ok, I managed to mount my fs again by disabling the entries in /etc/crypttab and by manually 'cryptsetup open'-ing one backing device after the other. As soon as a dev/dm-? becomes available the kernel correctly identifies it as a bcache backing device and automatically registers it. But when those devices are listed in /etc/crypttab, I consistently get that behavior I described in the first mail. Race condition maybe? j > >> August 13, 2017 4:27 PM, "Coly Li" <colyli@xxxxxxx> wrote: >> >> Hi Coly, >> >>> Could you please give me some hint how the /dev/dm- nodes are created ? >>> I will try to reproduce it on my hardware. >>> >>> Thanks for the report. >> >> I created them with 'cryptsetup luksFormat ...', IIRC. When I run 'cryptsetup luksDump' I get: >> >> Version: 1 >> Cipher name: aes >> Cipher mode: xts-plain64 >> Hash spec: sha256 >> Payload offset: 4096 >> MK bits: 256 >> MK digest: <STUFF> >> MK salt: <STUFF> >> MK iterations: 400000 >> UUID: 81a8d12e-9309-4317-b447-ab3c86e2f7ea >> >> Key Slot 0: ENABLED >> Iterations: 3200000 >> Salt: <STUFF> >> Key material offset: 8 >> AF stripes: 4000 >> >> and this is the contents of my /etc/crypttab: >> >> # <name> <device> <password> <options> >> crypted-sdb /dev/sdb1 /etc/cryptfs.key >> crypted-sdc /dev/sdc1 /etc/cryptfs.key >> crypted-sdd /dev/sdd1 /etc/cryptfs.key >> crypted-sde /dev/sde1 /etc/cryptfs.key > > Oh, I don't use cryptsetup before, let me try ... Thanks for the hint :-) > > Coly Li -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html