Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

When you want to use hibernation and you care for security, you'd like to have the swap encrypted. But not with the random password, chosen for you at startup, but with a fixed one, supplied by you at the boot time, so the hibernated state would be available for resuming upon next boot.

There was a cool way to do this, that worked up until Mint 15: How to: get the whole system encrypted

This doesn't work anymore on Petra. Can anyone help me with working it out? The main culprit, the /usr/share/initramfs-tools/scripts/local-top script didn't change, so I guess it has something to do with the kernel. It looks like the recent kernel just ignores all the scirpt, or at least the part that asks for a password for swap.

Oh, and I was able to get the password prompt, when I accidentally booted the Mint 16 with the kernel from Mint 15.

See also a related question:

How to ask for a password to mount crypted swap at boot time on Linux Mint 16 with initramfs-tools?


Some debug info

After opening the swap device with sudo cryptsetup luksOpen /dev/sda5 cryptswap:

sudo lsblk -o name,uuid

NAME                  UUID
sda                   
├─sda1                F251-38C0
├─sda2                c66b8e51-dd1b-4d92-8605-a3ba7df6af83
├─sda3                77af32db-038d-4c10-b302-039634cf943a
├─sda4                7a3cde35-ab80-4618-ad76-7aa064d55f56
├─sda5                fc068dd2-759c-4779-b521-c73cc5499e86
│ └─cryptswap (dm-1)  964eafeb-c88b-49c8-8b5e-6f8395e040b4
├─sda6                926fa7cc-6f97-4672-85a7-a1ed8f5bd842
├─sda7                804b9c88-907b-43d9-b23f-964c32ecc2ac
└─sda8                ce2cd926-133f-4e20-86f8-45bc4844271c
  └─adama-docs (dm-0) 61a32b98-3b65-4af6-81ff-da090cae039f
sr0              

cat /etc/crypttab

#cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
swap UUID=fc068dd2-759c-4779-b521-c73cc5499e86  none luks

cat /etc/fstab

UUID=926fa7cc-6f97-4672-85a7-a1ed8f5bd842   /   btrfs   defaults,subvol=@,compress,autodefrag   0   1
# /boot was on /dev/sda2 during installation
UUID=c66b8e51-dd1b-4d92-8605-a3ba7df6af83   /boot   ext3    defaults    0   2
# /boot/efi was on /dev/sda1 during installation
UUID=F251-38C0  /boot/efi   vfat    defaults    0   1
# /home was on /dev/sda6 during installation
UUID=926fa7cc-6f97-4672-85a7-a1ed8f5bd842   /home   btrfs   defaults,subvol=@home   0   2
# /mnt/ext4 was on /dev/sda7 during installation
UUID=804b9c88-907b-43d9-b23f-964c32ecc2ac   /mnt/ext4   ext4    defaults    0   0
# swap was on /dev/sda5 during installation
UUID=964eafeb-c88b-49c8-8b5e-6f8395e040b4 none            swap    sw              0       0

/etc/initramfs-tools/conf.d/resume

RESUME=/dev/disk/by-uuid/964eafeb-c88b-49c8-8b5e-6f8395e040b4

update:

When I setup everything like above, the system does display the familiar password prompt. It doesn't do that every time, and if it does, it is a fraction of second before the login screen (Linux Mint uses mdm for login). I guess there is racing condition; the mounting of swap is done parallel with the system booting; I expect the system to wait booting until the swap is mounted, and do it as early as possible. Otherwise how could it resume the hibernated state?

There is a similar question for Ubuntu: http://askubuntu.com/questions/396136/encrypted-home-partition-encrypted-swap-working-hibernate It seems, that it worked for someone if he encrypted the root as well.

share|improve this question
    
Could you write what you already did? –  Mikhail Morfikov Jan 12 at 14:18
    
@MikhailMorfikov thank you for your interest in helping me. I did exactly the steps from the forum forums.linuxmint.com/… which worked very well until new kernel came. –  Adam Ryczkowski Mar 2 at 15:11
    
Could you give content of the files and output of the commands in the answer? –  Mikhail Morfikov Mar 2 at 15:26
    
@MikhailMorfikov Question updated. –  Adam Ryczkowski Mar 2 at 15:33

1 Answer 1

I still don't know what setup you have, and what actually is going on when you try to hibernate your machine, but I'll try to answer the question.

I have debian testing distro, but I think there shouldn't be a problem to set this up on your pc. Just look at my setup, maybe you'll figure out what's wrong in your case.

This is my test disk:

root:~# lsblk -o name,uuid
NAME                  UUID
sda
├─sda1                727035387035047F
├─sda2                c55b13b7-ca46-488e-a78c-ac229cb6634c
├─sda3                1c379414-bac2-45d9-85c5-25163c663341
│ └─sda3_crypt (dm-0) 44cd4817-c27f-47aa-a7d5-b64276817a74
└─sda4                7774cf98-35fd-42fd-9891-7255c916fe02
  └─sda4 (dm-1)       0905595d-db03-4cc9-93d6-7d1262c140a4

sda2 is for boot partition, sda3, there's my linux, and sda4 is the swap partition. sda3 and sda4 are encrypted, and you want to unlock the swap partition at boot. You have to edit some files to do so.

/etc/fstab file:

UUID=0905595d-db03-4cc9-93d6-7d1262c140a4 swap swap defaults 0 0

/etc/initramfs-tools/conf.d/resume file:

RESUME=/dev/disk/by-uuid/0905595d-db03-4cc9-93d6-7d1262c140a4

/etc/crypttab file:

swap    UUID=7774cf98-35fd-42fd-9891-7255c916fe02   none    luks

Now you have to regenerate the initramfs:

update-initramfs -u -k all

This solution works for me on my testing debian. I didn't do anything else, booting, unlocking and hibernation work without a problem.

UPDATE

I think I figured that out. I installed the system and did what I had written in the answer, but this didn't work. Maybe it's because of upstart -- I'm using sysvinit. So I installed the system again, now using the encrypted build-in feature. Then I checked all the three files, and only the /etc/fstab file was different -- it appears that you can't use UUIDs in /etc/fstab when you want to mount or interact with encrypted devices. So, I installed the system once more (unencrypted), and I created a separate partition for swap. The two files /etc/initramfs-tools/conf.d/resume and /etc/crypttab stay the same, but in the /etc/fstab file I added the following line:

/dev/mapper/swap none            swap    sw              0       0

And it worked -- I had splash password screen, and it stopped booting until the right password was given. I also checked whether hibernation works, and it works as expected.

share|improve this answer
    
It doesn't work for Linux Mint 16. The computer never asks for a password, just displays a message about being unable to mount some disks (actually twice). I have an impression there is a problem with the local-top/cryptroot script. I've pasted it here pastebin.com/SFMBPiZg, so you can check whether your version is different from mine. –  Adam Ryczkowski Mar 2 at 15:28
    
Update: during boot, the system doesn't inform me that some of the disks failed to mount (it was a remnant from my previous attempts to solve the problem). Now it doesn't ask about anything, just fails to ask me for password and never informs me that something went wrong. –  Adam Ryczkowski Mar 2 at 15:36
    
You have wrong UUIDs. Don't copy it. Add fc068dd2-759c-4779-b521-c73cc5499e86 to the crypttab file, and 964eafeb-c88b-49c8-8b5e-6f8395e040b4 to fstab file. You also have to update the /etc/initramfs-tools/conf.d/resume file and add RESUME=/dev/disk/by-uuid/964eafeb-c88b-49c8-8b5e-6f8395e040b4. And then run update-initramfs -u -k all. And it will work –  Mikhail Morfikov Mar 2 at 16:47
    
Yes, unbelievable stupid mistake on my part... but still - I copied the right ones and PC didn't ask for a password. I've updated the question with the new contents of the mentioned files –  Adam Ryczkowski Mar 2 at 19:14
    
I think the problem is that the scripts /usr/share/initramfs-tools/scripts/local-top never actually try to do anything with the swap. Judging by their names (dmraid, cryptopensec and cryptroot), they were never designed to work with encrypted swap, and have no provisions for asking for a password for swap. That's why they were modified by the Mint forum member. I don't really know how to debug them (I guess it could be done using the recovery boot option by I have 0 experience). –  Adam Ryczkowski Mar 2 at 19:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.