Bug 755164

Summary: systemd will not enable LUKS-encrypted swap devices at boot
Product: [Fedora] Fedora Reporter: Deron Meranda <deron.meranda>
Component: systemdAssignee: systemd-maint
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: gregorio.gervasio, johannbg, johannbg, lpoetter, metherid, mschmidt, notting, plautrba, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-14 15:33:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of dmesg after boot with systemd in debug log mode
none
systemctl dump none

Description Deron Meranda 2011-11-19 09:03:31 UTC
Description of problem: At boot, the systemd "swap.target" unit will not enable swapping on any swap devices mentioned in /etc/fstab if those devices happen to be encrypted with LUKS. After the system has finished booting you can manually restart the swap.target unit, and then those encrypted devices will be enabled for swapping.


Version-Release number of selected component (if applicable):
systemd-37-3.fc16.x86_64
systemd-sysv-37-3.fc16.x86_64
systemd-units-37-3.fc16.x86_64


How reproducible: Always.  Worked in Fedora 15.


Steps to Reproduce:
1. Create a new device, say a logical volume, to hold a swap area. Set it up so it will be LUKS-encrypted with a random key, and add with an entry in /etc/crypttab similar to

luks-XXXX UUID=XXXX /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,swap

2. Add the device to /etc/fstab as a "swap" type and "defaults" option

3. Reboot, then check the /proc/swaps  

Actual results:
All non-encrypted swap devices will be enabled and show up in /proc/swaps; however any encrypted swap devices do not.

Expected results:
All swap devices listed in /etc/fstab should show up in /proc/swaps

Additional info:
I have checked that the systemd manager property SwapAuto=yes

My /etc/crypttab entry is:
luks-b1640161-ce10-40e3-a684-bc4b4c23b7d2 UUID=b1640161-ce10-40e3-a684-bc4b4c23b7d2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,swap

Comment 1 Michal Schmidt 2011-11-21 12:14:50 UTC
Problems with encrypted swaps may be related to bug 711150.
Are you seeing an ordering cycle logged in dmesg and/or /var/log/messages?

If it's not that, please boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" and attach the output of dmesg.

Comment 2 Deron Meranda 2011-11-21 21:52:20 UTC
Created attachment 534864 [details]
Output of dmesg after boot with systemd in debug log mode

Booted with systemd.log_level=debug, system versions:
kernel-3.1.1-2.fc16.x86_64
systemd-37-3.fc16.x86_64
systemd-sysv-37-3.fc16.x86_64
systemd-units-37-3.fc16.x86_64

Comment 3 Deron Meranda 2011-11-21 21:53:42 UTC
Created attachment 534866 [details]
systemctl dump

The output of "systemctl dump" after boot

Comment 4 Deron Meranda 2011-11-21 21:58:07 UTC
I attached more debugging information.  On this system I have two swap devices set up, one is LUKS encrypted, the other is not.

/dev/vg_beryl/lvswap    - LUKS encrypted swap (/dev/dm-5)
/dev/vg_beryl/lv_swap2  - a plain swap device (/dev/dm-14)

After boot, /proc/swaps contains:

Filename				Type		Size	Used	Priority
/dev/dm-14                              partition	1048572	0	0


If I then run "systemctl start swap.target", then /proc/swaps contains:

Filename				Type		Size	Used	Priority
/dev/dm-14                              partition	1048572	0	0
/dev/dm-18                              partition	33554428	0	0

Comment 5 Jóhann B. Guðmundsson 2012-01-29 20:02:20 UTC
Is this still an issue with the latest systemd release ( 37-11 ) or can this bug be closed?

Comment 6 Gregorio Gervasio 2012-02-06 07:01:40 UTC
Release 37-11 fixes the issue for me.

Comment 7 Lennart Poettering 2012-09-14 15:33:34 UTC
OK, closing.