You are not logged in.
I have to disks on my current computer. One is a 2TiB HDD and another is a 128GiB SSD. I'm planning to use the small but fast SSD to cache my large but slow HDD in writeback mode.
I first initialized the HDD as a LUKS encrypted device. After opening it, I initialized the mapped device as a physical volume of my LVM volume group. Then I created a logical volume within the volume group.
Then I initialized the SSD as a LUKS encrypted device as well. However, given the kernel command line only accept one "cryptdevice" parameter, I cannot unlock my SSD and HDD at the same time while booting. So the unlock time of my SSD might be delayed, given the HDD is the backend device of the cache model and the SSD is to decrypt with crypttab. I wonder whether it leads to problems during the booting if I expand my LVM volume group to the mapped device of my luks-opened SSD, as a physical volume cannot be found and some unique blocks are stored in it(given it's in the writeback mode).
Offline
I think you are correct and it won't work, because the volume won't activate due to missing PVs.
A much simpler version would be to have root (technically it can be really small < 1GiB when separating /usr) on the SSD for booting and setup everything else via crypttab this is honored as long crypttab is not disabled on the cmdline.
Offline
The sd-encrypt hook does not have the one device limitation.
Offline
Thanks for all your replies. However, I wonder if I use BCache, does it accept a latter add-on block device after boot? Also, if I configure the cache device into the write-back mode, will there be problems for not finding the cache device when loading the backend device?
Offline
My understanding of systemd early boot is all encrypted devices you specified to be opened in the initrd will be opened before anything is mounted.
Offline
It seems that I have to try sd-encrypt hook anyway ¯\_(ツ)_/¯
Offline