Encrypted swap hibernate part II

So as per documentation - https://help.ubuntu.com/community/En...s_and_Warnings - I am attempting this on a VM because if I screw up, it won't matter and as I expected I ran into issues and not sure what to do:

Any clues would be helpful

-edit

After rebooting anyways, I still have a working VM, only this time when I am in root and do a swapon --summary , there is no output.

Here I am assuming the last things you did are shown in the screenshot. I'm seeing a couple of things.

First, when you set up an encrypted partition by running "cryptsetup luksFormat ...", you are telling the cryptsetup program to prepare a LUKS header for a specific partition. This should be /dev/sdX and not /dev/dm-X. /dev/dm-X entries get created after "cryptsetup luksOpen ..." is run. Essentially you are double-LUKS'ing here.

Second, after you do get the partition properly "formatted", you need to manually set up swap space - this time on the 'dm' entry. You'll need to run, for example, "mkswap /dev/mapper/cryptswap1", before you can call "swapon".

To recap,
(1) cryptsetup luksFormat ... takes a physical partition /dev/sdX and creates a LUKS header on it. (It does NOT fill the partition with random data; you must do that yourself beforehand.)

(2) "cryptsetup luksOpen /dev/sdX name" unlocks the header and sets up a mapping from /dev/sdX to the name you choose, here cryptswap1. /dev/mapper/cryptswap1 depending on your udev version may be a symlink to a /dev/dm-X entry.

(3) mkswap /dev/mapper/cryptswap1 sets up swap space on the encrypted partition, the same as for a physical partition. Use the device mapper name and not the physical partition otherwise you will overwrite your LUKS header.

(4) swapon /dev/mapper/cryptswap1 should activate swap there.

You should also tell your /etc/fstab about this so that your system recognizes your new swap space after rebooting. Just change the swap entry from /dev/sdX or UUID=... to /dev/mapper/cryptswap1. You can also use the UUID shown by the mkswap command, but for starters try /dev/mapper/cryptswap1 to make sure it works. (Do not use /dev/dm-X - if you have multiple luks partitions the number of the entry dm-X may change across reboots.)

Originally Posted by ordealbyfire83 Here I am assuming the last things you did are shown in the screenshot. I'm seeing a couple of things. First, when you set up an encrypted partition by running "cryptsetup luksFormat ...", you are telling the cryptsetup program to prepare a LUKS header for a specific partition. This should be /dev/sdX and not /dev/dm-X. /dev/dm-X entries get created after "cryptsetup luksOpen ..." is run. Essentially you are double-LUKS'ing here. Second, after you do get the partition properly "formatted", you need to manually set up swap space - this time on the 'dm' entry. You'll need to run, for example, "mkswap /dev/mapper/cryptswap1", before you can call "swapon". To recap, (1) cryptsetup luksFormat ... takes a physical partition /dev/sdX and creates a LUKS header on it. (It does NOT fill the partition with random data; you must do that yourself beforehand.) (2) "cryptsetup luksOpen /dev/sdX name" unlocks the header and sets up a mapping from /dev/sdX to the name you choose, here cryptswap1. /dev/mapper/cryptswap1 depending on your udev version may be a symlink to a /dev/dm-X entry. (3) mkswap /dev/mapper/cryptswap1 sets up swap space on the encrypted partition, the same as for a physical partition. Use the device mapper name and not the physical partition otherwise you will overwrite your LUKS header. (4) swapon /dev/mapper/cryptswap1 should activate swap there. You should also tell your /etc/fstab about this so that your system recognizes your new swap space after rebooting. Just change the swap entry from /dev/sdX or UUID=... to /dev/mapper/cryptswap1. You can also use the UUID shown by the mkswap command, but for starters try /dev/mapper/cryptswap1 to make sure it works. (Do not use /dev/dm-X - if you have multiple luks partitions the number of the entry dm-X may change across reboots.)

Here is the thing, I didn't do anything with the CLI when setting up the partitioning scheme. During install the Devuan installer of course uses a GUI; I guess that is both a good and a bad thing. The good thing is I am much too lazy & dumb (mainly the latter), to setup an encrypted partitioning scheme and LUKs. Only bad thing is that means on other distros that don't even use ncurses for setting up encrypted LUKs(Slackware), leaves me kinda screwed.

As for sdX, that is the problem for me because it sda5 is the extended partition which holds the encrypted LUKs. So AFAIK it gets complicated (maybe it really isn't and I am over thinking it), but since all I see is sda5, swap is on sda5 which well technically it is, but that cannot be right. It cannot be right in essence that I should just choose sda5 only, because won't that just screw up the entire LUKs partition? This is another reason why I am completely messing with this on a VM first.

So maybe there is another route, lsblk shows this:

devuser@devuan:~$ lsblk
NAME              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                 8:0    0   86G  0 disk  
├─sda1              8:1    0  116M  0 part  /boot
├─sda2              8:2    0    1K  0 part  
└─sda5              8:5    0 85.9G  0 part  
  └─sda5_crypt    254:0    0 85.9G  0 crypt 
    ├─volume-root 254:1    0   30G  0 lvm   /
    ├─volume-swap 254:2    0 15.3G  0 lvm   [SWAP]
    └─volume-home 254:3    0 40.6G  0 lvm   /home
sr0                11:0    1 1024M  0 rom   
devuser@devuan:~$

Or not, sda5 is crypt but all I know is per the last screen shot it is /dev/dm-2 ? This is where I am completely confused anyways, which though again if I fsck it up, I don't care because it is a VM. The only thing is this is the exact type of partitioning scheme I have setup on my notebook as I do on the VM.

Ok, now we're getting somewhere. It wasn't clear from the screenshot that you're using LVM. Automated installers love LVM nowadays.

From the output of 'lsblk' sda5 is the root of the logical volume which itself contains a LUKS header. For this reason, sda5 is NOT visible to the operating system as a LUKS partition - the logical volume sda5 is.

Inside this encrypted logical volume you have three other logical volumes which, though encrypted, are probably unlocked using the key/password for the sda5-logical volume rather than individual LUKS partitions.

I guess all you really need to do is find the /dev entry for "volume-swap", set up swap space there, activate it, and add it to your /etc/fstab. The installer didn't do that, I guess, so that's likely a bug.

The device entry for that particular volume is probably set by udev and depending on the version and OS conventions that could vary, so you might have to poke around until you find it. In /dev, look for directories like /dev/volgroup or /dev/mapper.

Originally Posted by ordealbyfire83 Ok, now we're getting somewhere. It wasn't clear from the screenshot that you're using LVM. Automated installers love LVM nowadays. From the output of 'lsblk' sda5 is the root of the logical volume which itself contains a LUKS header. For this reason, sda5 is NOT visible to the operating system as a LUKS partition - the logical volume sda5 is. Inside this encrypted logical volume you have three other logical volumes which, though encrypted, are probably unlocked using the key/password for the sda5-logical volume rather than individual LUKS partitions.

Yep:

Originally Posted by ordealbyfire83 I guess all you really need to do is find the /dev entry for "volume-swap", set up swap space there, activate it, and add it to your /etc/fstab. The installer didn't do that, I guess, so that's likely a bug.

Perhaps, again I did not do any of this on a CLI, just used the Devuan installer

Originally Posted by ordealbyfire83 The device entry for that particular volume is probably set by udev and depending on the version and OS conventions that could vary, so you might have to poke around until you find it. In /dev, look for directories like /dev/volgroup or /dev/mapper.

Well this is my fstab and crypttab:

fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/volume-root /               jfs     errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=c8c98d6d-3804-4a4d-83d4-d0805dafb9aa /boot           jfs     defaults        0       2
/dev/mapper/volume-home /home           xfs     defaults        0       0
/dev/mapper/volume-swap none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

/etc/crypttab

sda5_crypt UUID=dcc4a98c-e52b-4066-91ce-5075047388dc none luks

And I double checked - swap is on:

root@devuan:/home/devuser# swapon --summary
Filename				Type		Size	Used	Priority
/dev/dm-2                              	partition	15994876	0	-1
root@devuan:/home/devuser#

So do you actually have swap available? Do you have nonzero output on the swap line from 'free -m'? In theory it looks like you should have this working.

Those error messages in your screenshot are to be expected. Basically what's happening is your kernel is reading arguments from your bootloader that don't exist yet. The grub 'kernel' (or 'linux' if in grub2) line probably has root=/dev/mapper/... and resume=/dev/mapper/.... Debian's initrd basically works like this

- Parse kernel command arguments and try to boot.
- No go, arguments show /dev/mapper stuff, so try lvm
- lvm stuff not active, is it encrypted?
- Check /etc/crypttab
- If Yes, unlock partition
- Try again

Their initrd has quite a lot of dark corners. The /etc/crypttab file is nothing standards-based and is only used by Debian-based initrd's. It would of course be better to make your own initrd that does exactly what you need, but that's an area that most people avoid. Unfortunately, as the kernel doesn't _natively_ support luks, an initrd is needed to create the necessary device notes and jump-start the system that way.

Just a heads up, if you have problems with hibernate/resume, LVM, not LUKS, is the likely culprit.

Originally Posted by ordealbyfire83 So do you actually have swap available? Do you have nonzero output on the swap line from 'free -m'? In theory it looks like you should have this working.

Correct, no swap is being used:

devuser@devuan:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          16051         374       15336          16         340       15402
Swap:         15619           0       15619
devuser@devuan:~$

Originally Posted by ordealbyfire83 Those error messages in your screenshot are to be expected. Basically what's happening is your kernel is reading arguments from your bootloader that don't exist yet. The grub 'kernel' (or 'linux' if in grub2) line probably has root=/dev/mapper/... and resume=/dev/mapper/.... Debian's initrd basically works like this - Parse kernel command arguments and try to boot. - No go, arguments show /dev/mapper stuff, so try lvm - lvm stuff not active, is it encrypted? - Check /etc/crypttab - If Yes, unlock partition - Try again Their initrd has quite a lot of dark corners. The /etc/crypttab file is nothing standards-based and is only used by Debian-based initrd's. It would of course be better to make your own initrd that does exactly what you need, but that's an area that most people avoid. Unfortunately, as the kernel doesn't _natively_ support luks, an initrd is needed to create the necessary device notes and jump-start the system that way. Just a heads up, if you have problems with hibernate/resume, LVM, not LUKS, is the likely culprit.

Perhaps again I am also making things more difficult. I am trying every which way to get a grasp on this entire concept with no success. Even before all this I have been reading README_LVM.TXT and README_CRYPT.TXT (within Slackware), I just do not get it (because yea I am dumb). Plus according to the Slackware way, you can't or shouldn't do an encrypted LVM/SWAP (cannot remember where I read it in those docs).

Either way now I feel really over my head in all this. I haven't given up yet, but yea I wish there was a more 'efficient' way, whatever that is.

My apologies for the delay. I read through those files and indeed they are more complex than they need to be. Probably the best way to get more insight is to experiment with some pure LUKS containers (without LVM). There are any number of configuration options for creating a container, and most of that comes down to personal preference, level of paranoia, and the like. You can practice with creating containers that can be unlocked with a password or with a key file.

(As a warning, before deploying storage containers for production use, you should always make a backup container on a separate physical disk - if a hard drive fails, traditional data recovery methods likely will probably not work, even if you have the LUKS header.)

Most advocates for LVM claim that you can unlock multiple partitions with a single password for the sake of convenience (i.e. not having to unlock the root partition and swap separately). But one way around this is to make the swap unlockable with a key file and store that key on the root partition. That way, in your initrd you can write an instruction to unlock the swap automatically after the root partition is unlocked via your password.

The goal of the initrd would be to boot the kernel, mount a very minimal runtime environment, load the necessary kernel modules, unlock the partitions, mount the real root partition, and then switch_root to let the actual system boot up, or resume from swap. Initrd's such as Debian's are anything but simple and have a full-scale OS in there, which in my view, is a gaping security risk (i.e. do you really want networking and system administration utilies in there).

But alas, without writing your own initrd you are essentially stuck with using whatever method your distribution uses. But at least with some practice you could at least grasp what that initrd's procedure is and go with that.

Originally Posted by ordealbyfire83 My apologies for the delay. I read through those files and indeed they are more complex than they need to be. Probably the best way to get more insight is to experiment with some pure LUKS containers (without LVM). There are any number of configuration options for creating a container, and most of that comes down to personal preference, level of paranoia, and the like. You can practice with creating containers that can be unlocked with a password or with a key file.

No problem. As for this encryption thing I would find it a good idea to utilize it when possible. I.e. like a notebook something that you would have on hand away from home. I mean yea sure you can also encrypt your home computer's drive, but I dunno.

Originally Posted by ordealbyfire83 (As a warning, before deploying storage containers for production use, you should always make a backup container on a separate physical disk - if a hard drive fails, traditional data recovery methods likely will probably not work, even if you have the LUKS header.) Most advocates for LVM claim that you can unlock multiple partitions with a single password for the sake of convenience (i.e. not having to unlock the root partition and swap separately). But one way around this is to make the swap unlockable with a key file and store that key on the root partition. That way, in your initrd you can write an instruction to unlock the swap automatically after the root partition is unlocked via your password.

Hrmm, then maybe I should have multiple strategies, keep using both optical media and external HDs. Though I think encrypting external HDs might be more cumbersome and trouble than its worth. Also say if one has multiple HDs in a machine like I do, a primary SSD for the OS , and a conventional HD for /home, then I would have to probably enter the password twice still anyways? Yea encryption and LUKs are kinda involved.

Originally Posted by ordealbyfire83 The goal of the initrd would be to boot the kernel, mount a very minimal runtime environment, load the necessary kernel modules, unlock the partitions, mount the real root partition, and then switch_root to let the actual system boot up, or resume from swap. Initrd's such as Debian's are anything but simple and have a full-scale OS in there, which in my view, is a gaping security risk (i.e. do you really want networking and system administration utilies in there).

This then would come down to the level security vs practicality then.

Originally Posted by ordealbyfire83 But alas, without writing your own initrd you are essentially stuck with using whatever method your distribution uses. But at least with some practice you could at least grasp what that initrd's procedure is and go with that.

I guess again thats where I am held hostage. In terms of Slackware the documentation is itself involved, and yet not complete and it is all done by hand. I actually cannot even write a script to save my life. I kinda wish there was something middle of the road. I don't need a GUI , though some would argue that ncurses counts as one, I would be happy if Slackware at least had something like that in it's ncurses when setting things up initially, but it does not.

Sure Debian/Devuan you have the GUI and you don't have to worry about it, thats fine too. Even better if you are a lazy idiot . I am just lazy enough not to want to do something like this in a CLI, but thats just me.

As for this encryption thing I would find it a good idea to utilize it when possible. I.e. like a notebook something that you would have on hand away from home. I mean yea sure you can also encrypt your home computer's drive, but I dunno.

In addition to issues related to physical access, it's also a way of avoiding data remanence. With SSD's becoming more common, it's worth bearing in mind how they actually work. Unlike traditional drives which contain a small amount of extra sectors to use in case one goes bad, the true capacity of a SSD can be 50% greater than the advertised capacity. This "wear-leveling" tactic is what makes SSD's more reliable than flash drives. However, this extra capacity is inaccessible to the OS and cannot be erased this side of an external programmer, no matter how many times you run dd if=/dev/urandom of=/dev/sdX. The only way around this is to use brand new SSD's and only write encrypted data to them.

Further, using LUKS does slow things down a bit and this may cause some mismatch in data transfer rates to/from your SSD. The latest, blazing-speed drive isn't your friend here. This is somewhat of an edge case that the kernel developers seem not to give much attention to. If there is an issue you can try adjusting the kernel's dirty ratio and/or using something other than the cfq I/O scheduler. (Hint: you need to use the same scheduler for ALL connected storage devices (try setting it on the grub command line using elevator=deadline or similar) or else you'll get real trouble - think lockups requiring hard reset and fsck.)

echo 10 > /proc/sys/vm/dirty_ratio
echo 3 > /proc/sys/vm/dirty_background_ratio

But in any event even home computers should be secured, particularly for those living in rental properties or anywhere else where others have a key.

Encrypting external devices isn't much trouble. Depending on how your distribution compiled your desktop environment (if you're using one), Caja, Dolphin, and friends might prompt you with a password entry box. This should work for KDE 5, the newest versions of KDE 4, and Mate provided that cryptsetup was available at compile time.

Another thing to consider is whether your distribution uses or can use an /etc/rc.local file or similar. This is a file read by your init system and run at the end of the boot process. You can unlock multiple non-root drives here to avoid fiddling with an initrd. You'll need to set up a keyfile based unlocking scheme and place the key somewhere on your root partition (this is tolerable only if the root partition is encrypted). Then you could add a line similar to

cryptsetup luksOpen --key-file /etc/your-key-file /dev/sdXn mapper_name

If you decide to go the initrd route, remember you need to include every program you need and all of the shared objects down to libc. How much or how little you need is your call - I only have about 28 shared objects and about equally many programs. (As a test, you'll need to be able to chroot to its parent directory and be able to run the programs successfully with no access to your host OS.) At one time I started writing a tutorial for this but have yet to finish. It's one of those things that took a lot of hair-pulling to figure out but in retrospect looks ridiculously simple.

I guess the easiest would be to use the distribution's way of encrypting the root partition and getting this unlocked at boot time. Then use rc.local for unlocking all the non-root fixed drives, and handling external drives either on the command line or leaving that to your file manager.

Originally Posted by ordealbyfire83 I guess the easiest would be to use the distribution's way of encrypting the root partition and getting this unlocked at boot time. Then use rc.local for unlocking all the non-root fixed drives, and handling external drives either on the command line or leaving that to your file manager.

I consider the Devuan setup fairly easy. Slackware is lacking in a point-and-click gui, which is fine by me. I just wish during setup it could be done through ncurses since that is used during the partitioning and selecting the software for installation in Slackware.