$ sudo update-initramfs -u
$ grep crypt /etc/crypttabupdate-initramfs: Generating /boot/initrd.img-6.1.0-25-amd64
...cryptsetup: ERROR: sdb5_crypt: Source mismatch
$ sudo blkid|grep cryptsdb5_crypt UUID=UID1HERE none luks,discard
/dev/nvme0n1p5 is the clone of the /dev/sda5 if i am not mistaken - so the cause of the "source mismatch" MAY be this duplicity of UUIDs, but i have doubts/dev/nvme0n1p5: UUID="UID1HERE" TYPE="crypto_LUKS" PARTUUID="UID1bHERE"
/dev/mapper/sdb5_crypt: UUID="UID2HERE" TYPE="LVM2_member"
/dev/sda5: UUID="UID1HERE" TYPE="crypto_LUKS" PARTUUID="UID1bHERE"
This command works to get rid of the mismatch error in initramfs update:
sudo cryptsetup luksUUID --uuid=newuuid /dev/sda5
I am unsure if it is good idea but system booted later on, though running again above mentioned blkid and /etc/crypttab output commands, it still shows duplicity across the drives, yet somehow the "update-initramfs -u" no longer complains, I am unsure what fixed this issue. If it was really the UUID change command which modified UUID somewhere internally.
I have replaced "errors=remount-ro" by "errors=remount-ro,nofail" inside /etc/fstab as someone suggested.
Bookmarks