You are not logged in.
Normal partition /dev/sda6 with and ext4 filesystem containing some data. I'm experimenting with turning it to an encrypted partition (LUKS2) and reverting back.
1. For encryption I've followed:
https://wiki.archlinux.org/title/Dm-cry … ile_system
and it seems to work perfectly.
2. Let's try reverting the changes. I used:
https://wiki.archlinux.org/title/Removi … s_in-place
and I'm afraid I'm missing something :-( After successful run LUKS doesn't recognize it as a LUKS volume while utilities like mount or e2fsck don't recognize it as an ext4 partition. Seems like some "trash" is left in first sectors..? I'd really appreciate any suggestion.
Offline
Just my opinion, but I find in-place encryption and reversion a bit pointless. The only surefire way to ensure against data loss is to have a backup, preferably hosted on a different computer or the cloud. The irony here is that if you already have a backup, you don't really need these in-place processes, since you can just nuke the partition, encrypt it the normal way, and then restore your data into the newly-encrypted partition.
Even if your experiment ended successfully, there is no guarantee that it will be successful the next time you try it on a working partition. If it fails and you don't have a backup, then the data in the partition is lost forever.
Never argue with an idiot, they will drag you down to their level and then beat you with experience.
It is better to light a candle than curse the darkness.
A journey of a thousand miles begins with a single step.
Offline
Well, yes but actually no. I agree that for ANY filesystem changes it's safer to create a backup copy, apply changes and restore the data. However from the scientific point of view... As I wrote: I'm just experimenting. If there is a tool or an option I'd like to know as much possible about it.
Offline
Pretty much can't comment if you don't show the commands you used, outputs, luksDump (of the device or header file) etc.
If done correctly, it should work, but converting anything in-place is always dangerous, so. And people rarely do this, so entirely possible there are bugs.
Online
Exactly as in the linked documents:
Encryption:
# mkfs.ext4 /dev/sda6
<mount, create some content, umount>
# e2fsck -f /dev/sda6
# resize2fs -p -M /dev/sda6
# cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/sda6
# cryptsetup open /dev/sda6 sei
# e2fsck -f /dev/mapper/sei
# resize2fs /dev/mapper/sei
# mount /dev/mapper/sei /mnt/
<the content is fine>
And back (the second linked URL)
# umount /mnt
# cryptsetup close sei
# cryptsetup reencrypt --decrypt --header luks.header /dev/sda6
Result:
# cryptsetup <whatever>
Device /dev/sda6 is not a valid LUKS device.
# mount /dev/sda6 /mnt/
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda6, missing codepage or helper program, or other error.
Last edited by quayasil (2024-10-03 14:17:40)
Offline
For LUKS1 it works fine so for decryption the following commands work (first convert LUKS2 to LUKS1 then decrypt):
# cryptsetup luksChangeKey --pbkdf pbkdf2 /dev/sda6
# cryptsetup convert --type luks1 /dev/sda6
# cryptsetup reencrypt --decrypt /dev/sda6
ArchWiki: https://wiki.archlinux.org/title/Removi … s_in-place would work if a header was stored in a separate file.
Information "The new_file to which the LUKS2 header will be migrated must not exist in the initialization phase of the decryption." is WRONG!
Last edited by quayasil (2024-10-13 08:32:27)
Offline
It's best to use an absolute path, e.g. --header /root/luks.header because you can't have the temporary exported header to the mount point (/mnt in your case).
Offline