Community Bot 1. Does the crypt target show up after you manually do luksOpen? I'd expect that if it wasn't there, luksOpen would fail too.
Ok, after sudo cryptsetup luksOpen two new targets appear for sudo dmsetup targets : error and crypt. I guess I need to change the question then Is it a partition or a file container? Do you know if crypttab works with LVM volumes? All mounted at boot without a problem. Can you show the output of lsblk -o name,uuid,mountpoint when everything is mounted and works as it should? Show 4 more comments.
Active Oldest Votes. You have to pay attention to UUIDs. Improve this answer. Mikhail Morfikov Mikhail Morfikov 9, 16 16 gold badges 60 60 silver badges 93 93 bronze badges. I will update the question with details. Hi, this is getting a bit too long, can we chat?
This answer helped me fix the mistakes I made with disks and perhaps more mistake when trying to undo disks. Add a comment. Encryption has no influence on that. Backup is mandatory for encrypted data as well, if the data has any worth.
See the Cryptsetup FAQ for advice on how to do backup of an encrypted volume. Character encoding: If you enter a passphrase with special symbols, the passphrase can change depending character encoding. Keyboard settings can also change, which can make blind input hard or impossible. For example, switching from some ASCII 8-bit variant to UTF-8 can lead to a different binary encoding and hence different passphrase seen by cryptsetup, even if what you see on the terminal is exactly the same.
If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with known passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wiping by just overwriting header and key-slot area.
Previously used partitions: If a partition was previously used, it is a very good idea to wipe filesystem signatures, data, etc. For a quick removal of filesystem signatures, use "wipefs". Take care though that this may not remove everything. In particular md RAID signatures at the end of a device may survive.
It also does not remove data. For a full wipe, overwrite the whole partition before container creation. If you do not know how to to that, the cryptsetup FAQ describes several options. Device type can be plain , luks default , loopaes or tcrypt. For backward compatibility there are close command aliases: remove , plainClose , luksClose , loopaesClose , tcryptClose all behaves exactly the same, device type is determined automatically from active device.
If --size in sectors is not specified, the size of the underlying block device is used. Note that this does not change the raw device geometry, it just changes how many sectors of the raw device are represented in the mapped device.
No checks are performed, no metadata is used. There is no formatting operation. When the raw device is mapped opened , the usual device operations can be used on the mapped device, including filesystem creation. It adds a standardized header at the start of the device, a key-slot area directly behind the header and the bulk data area behind that.
The whole set is called a 'LUKS container'. For most purposes both terms can be used interchangeably. LUKS can manage multiple passphrases that can be individually revoked or changed and that can be securely scrubbed from persistent media due to the use of anti-forensic stripes. Passphrases are protected against brute-force and dictionary attacks by PBKDF2, which implements hash iteration and salting in one function.
Each passphrase, also called a key in this document, is associated with one of 8 key- slots. Key operations that do not specify a slot affect the first slot that matches the supplied passphrase or the first empty slot if a new passphrase is added. Note that if the second argument is present, then the passphrase is taken from the file given there, without the need to use the --key-file option.
Also note that for both forms of reading the passphrase from file you can give '-' as file name, which results in the passphrase being read from stdin and the safety-question being skipped. If the passphrase is not supplied via --key-file, the command prompts for it interactively. Needs kernel 2.
After this operation you have to use luksResume to reinstate the encryption key and unblock the device or close to remove the mapped device.
Prompts interactively for a passphrase if --key-file is not given. An existing passphrase must be supplied interactively or via --key-file. The new passphrase to be added can be specified interactively or read from the file given as positional argument. The passphrase to be removed can be specified interactively, as positional argument or via --key-file. Removing the last passphrase makes the LUKS container permanently inaccessible.
The passphrase to be changed must be supplied interactively or via --key-file. The new passphrase can be supplied interactively or in a file given as positional argument. If a key-slot is specified via --key-slot , the passphrase for that key-slot must be given and the new passphrase will overwrite the specified key-slot.
If no key- slot is specified and there is still a free key-slot, then the new passphrase will be put into a free key-slot before the key-slot containing the old passphrase is purged.
If there is no free key-slot, then the key-slot with the old passphrase is overwritten directly. A remaining passphrase must be supplied, either interactively or via --key-file. This command can remove the last remaining key-slot, but requires an interactive confirmation when doing so. Removing the last passphrase makes a LUKS container permanently inaccessible.
WARNING: If you read the passphrase from stdin without further argument or with '-' as argument to --key-file , batch-mode -q will be implicitely switched on and no warning will be given when you remove the last remaining passphrase from a LUKS container. You do not need to provide any password for this operation. Set new UUID if --uuid option is specified. Use option -v to get human-readable feedback. If the --dump-master-key option is used, the LUKS device master key is dumped instead of the keyslot info.
Beware that the master key cannot be changed and can be used to decrypt the data stored in the LUKS container without a passphrase and even without the LUKS header. This means that if the master key is compromised, the whole device has to be erased to prevent further access. Use this option carefully. In order to dump the master key, a passphrase has to be supplied, either interactively or via --key-file. After about a 5 minute wait, it will come up with a BusyBox initramfs prompt.
My question is, why won't it ask for the boot passphrase when booted this way from either disk? I did choose the option to continue booting after a disk failure when I installed the RAID partition, but this obviously isn't happening. EDIT: As requested, here's the output of pvdisplay run after it boots with both drive plugged in:. When only one drive is plugged in, it eventually drops me to a BusyBox shell where pvdisplay is not available.
It appears to have been fixed, so I manually installed the updated cryptsetup, libcryptsetup1, and libpop0 packages from upstream. Now when I boot with either disk unplugged, I don't get the error anymore, and it asks for a passphrase properly.
However, it won't accept the password I've configured. With both disks plugged in, it accepts the password and boots as normal, but with either one unplugged it gets to asking for the passphrase won't accept the correct password.
This seems like a bizarre procedure to get it to boot in a degraded state. I think I'm going to wipe everything and start over. Since I haven't run into this before I'm hoping a fresh install may fix things, and if not I at least know how to boot the degraded array if I need to. I know you want to use the UUID to mount it, but apparently that is not supported right out of the box. Sign up to join this community. Information forwarded to debian-bugs-dist lists. Message 14 received at bugs.
Forcibly Merged Wed, 07 Apr GMT full text , mbox , link. Message 21 received at bugs. Message 26 received at bugs. Thu, 08 Apr GMT full text , mbox , link. Message 31 received at close bugs.
0コメント