Re: Problem after detaching the header
Milan Broz <[email protected]> Sat, 1 Jul 2023 23:00:16 +0200
| Newsgroups | dev.linux.lists.cryptsetup |
|---|---|
| Message-ID | <[email protected]> |
On 7/1/23 19:06, Darek Hisc wrote: > >> - luksErase will destroy keyslots (key material) > Does it also destroy the Master Key? Volume Key (also known as Master Key) is stored in keyslot(s). luksErase removes all keyslots, thus removes all keys, see man cryptsetup-luksErase >> but still keeps LUKS header on the device, including UUID (so you can reference the device through UUID >> even if it cannot be unlocked without detached header) > From the comments I've received here https://unix.stackexchange.com/questions/750288/properly-detach-the-luks-header-from-the-existing-fdelvm-encryption it also appears that the missing UUID is to blame after destroying the entire header. > >> Check that UUID is not referenced in config. > How to check? It depends on your distro. Crypttab, bootloader config, old blkid cache, whatever. I have no idea, it was just a hint. The FAQ contains generic info, various distros can have various additional steps (we should update it to mention it, though). > >> But as Arno said, this is really question for your distro (note that cryptab >> file can be managed by systemd, but there are also non-systemd versions). > If it's not a cryptsetup problem, it probably affects many (or all) distributions. I suggest to add the relevant information to FAQ 2.20 because the current wording suggests that the given procedure is sufficient and it is not (because it causes a UUID problem that needs to be solved somehow) > >> Also without console log it is not clear what exactly fails. > Please tell me what to enter in the initramfs console to check it and I will give you the result > > Another solution that looks very interesting: > In a comment on stackexchange, someone suggested creating a dummy header instead of the original one, but using a detached one. Do you see any potential problems and is this a good idea? LUKS header after calling luksErase is actually "dummy" header (if it means header without keyslots). So I think this is what you get after calling luksErase in your steps 1-5. Your device can be only unlocked with detached header, but data device is still visible marked as LUKS, that should be enough if your goal is to store key separately. Milan