I think there are two things you’re missing here: (a) Your command to open the encrypted container is wrong, and (b) I think you might be missing the relationship between the device encryption and the partitions you’ve created. Formatting doesn’t look like it came through 100%, so hopefully I’m not misinterpreting things…
(a) I think your main problem may just be that your
cryptsetup command is wrong. You want to use something like the following:
sudo cryptsetup luksOpen /dev/sda1 foo
foo is just a friendly name – it can be anything you want, within reason. This will create a special device (
/dev/dm-0, or something similar) that transparently maps an unencrypted view of the data in the encrypted container with the actual (encrypted) device. It will also create a symlink called
/dev/mapper/foo that points to that mapped device so that you have a consistent name to work with (this is useful because the actual device name will depend on how many other encrypted devices you’re mapping).
man cryptsetup for a more exhaustive discussion of the various options.
Of course, there’s probably no filesystem on
/dev/mapper/foo yet – you’ll still need to format it, and then decide where you want to mount it. So the general first-run steps will be something like:
- “Format” the partition using
cryptsetup luksFormat (this sets up the encrypted container).
- “Open” the partition using
cryptsetup luksOpen (this creates a mapping between the unencrypted view of the container and the actual encrypted data on disk).
- Format the mapped device (
/dev/mapper/foo) with a filesystem like ext4 (so you can actually write files to it).
- Finally, mount that filesystem somewhere so that you can write normal files to it with normal applications.
(b) In general, storage is set up a bit like an onion these days.
You start with the device itself (
Generally, you then write a partition table to that device to help organize your data (
/dev/sda1). You don’t always need to do this (I’ve seen lots of thumb drives that just have the file system written directly to
/dev/sdX), but it gives you flexibility, and it’s generally (always?) needed to make something bootable. Partitions just hold data though…
Once you have your partitions, what comes next is a bit of a choose-your-own adventure. Sometimes you write a file system directly to a partition you created. Sometimes you write an encrypted container. Sometimes you write another partition-like scheme like LVM, and then you write a file system to that. You can mix-and-match here, depending on your needs. (For example, back in the day I used to drop LVM inside of a container encrypted with LUKS, and then write my
/home, etc. file systems to that. That way I could get nearly full disk encryption with only a single passphrase.) And modern file systems like BTRFS and ZFS really blur the line between “partition” and “file system” with concepts like pools, etc. (I’m getting beyond my meager knowledge here though.)
Anyways, the point here is that disk partitions just hold data. Think of them like a cooking pot – sometimes that pot holds water, sometimes it holds stew. The data inside the partition might be a file system, it might be an encrypted container, or it might be something more complex to fit a particular use case. To get rid of the data on a partition, just write other data over it. To get rid of the partition, just delete it with your partition tool.
Hopefully, something here is helpful for you.