Bug 768880

Summary: cannot detach encrypted / on shutdown/halt
Product: [Fedora] Fedora Reporter: Daniel <daniel>
Component: systemdAssignee: systemd-maint
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, itamar, johannbg, jonathan, kernel-maint, lpoetter, madhu.chinakonda, metherid, mschmidt, notting, plautrba, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-14 14:11:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
dmesg.txt.old.bz2
none
dmesg.txt.older.bz2
none
dmesg.txt.bz2 2012-01-03
none
dmesg-2012_01_10.txt.bz2 none

Description Daniel 2011-12-19 09:28:50 UTC 
Description of problem: Lenovo X300-Notebook with encrupted / and swap-Partition. Beginning from second(?) Kernel-Update the system does not schot down properly. It takes about 5 minutes to shut down and an error message

cryptsetup Failed to deactivate: Device or resource

is to be shown. Did run Fedora beginning from F13 on the same machine and this never happened before.
Strange enough, the same does not happen on a desktop system with the same setting. Maybe the ATA driver is part of the problem?

Version-Release number of selected component (if applicable): kernel-3.1.5-6.fc16.x86_64
Comment 1 Daniel 2011-12-19 09:54:38 UTC 
Forgot to say, that this happened after using vpnc sessions. If no vpnc was started, system reboot/halt are as expected. Very wired.
Comment 2 Daniel 2011-12-21 07:36:10 UTC 
Played a bit around. Even without using vpnc I'll get a longer delay and twice the
"cryptsetup Failed to deactivate: Device or resource" error message.
Comment 3 Michal Schmidt 2011-12-21 22:17:01 UTC 
To collect useful information for debugging please do the following:
 - Save the following script as /lib/systemd/system-shutdown/debug.sh:

#!/bin/sh
mount -o remount,rw /
dmesg > /dmesg.txt
mount -o remount,ro /

   Make sure it's executable (chmod +x ...).

 - Next time you boot, add the following parameters to the kernel command line
   in GRUB:
   log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg

 - Before you shutdown, make sure SELinux is not in enforcing mode. You can use:
   setenforce 0

 - Do the shutdown.

 - If you have reproduced the bug during the shutdown, attach the resulting file
   /dmesg.txt to this Bugzilla.
Comment 4 Daniel 2012-01-02 06:12:28 UTC 
Unfortunately this helps not so much, dmesg.txt is empty. However I've attached some dmesg.txt created otherwise.
Comment 5 Daniel 2012-01-02 06:15:05 UTC 
Created attachment 550189 [details]
dmesg.txt.old.bz2
Comment 6 Daniel 2012-01-02 06:15:55 UTC 
Created attachment 550190 [details]
dmesg.txt.older.bz2
Comment 7 Michal Schmidt 2012-01-02 10:11:10 UTC 
Are you sure SELinux was not in enforcing mode? I can't think of any other reason for the file to come out empty.
Comment 8 Daniel 2012-01-03 22:20:16 UTC 
Created attachment 550549 [details]
dmesg.txt.bz2 2012-01-03
Comment 9 Daniel 2012-01-03 22:21:47 UTC 
Next try; now rebooting/halt goes relatively fast; and this time dmesg.txt is not empty, see attachement above (2012-01-03).
Comment 10 Daniel 2012-01-10 12:47:20 UTC 
Created attachment 551830 [details]
dmesg-2012_01_10.txt.bz2
Comment 11 Lennart Poettering 2012-08-08 23:10:26 UTC 
If the root file system is encrypted we cannot destruct it. That's obvious, no? What did you expect?
Comment 12 Daniel 2012-09-14 08:53:44 UTC 
Same machine, same setting but Fedora 17: the problem does not exist anymore. So we should close this bug.