Bug 704894

Summary: F15 cannot shut down/reboot with encrypted disk
Product: [Fedora] Fedora Reporter: Jason Haar <jhaar>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: agk, c.hirschmann-bugs, dad, dwysocha, gansalmon, itamar, jonathan, kernel-maint, lvm-team, madhu.chinakonda, mbroz, philip, pjones, prockai, sirio400516x, whulbert
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-07-11 17:52:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jason Haar 2011-05-15 20:25:30 UTC
Description of problem:

I chose to encrypt my harddisk during the install of F15Beta2. Ever since I have been unable to shutdown/reboot - I always have to use the power button

The shutdown GUI shows no error, so instead I logged into a console as root, typed "reboot" and hit ESC. I then saw

----------------------------------------------------------------------
Detaching DM devices
Could not delete dm /deb/dm-0: Device or resource busy
Not all DM devices deleted, 2 left
Cannot finalize remaining file systems and devices, trying to kill remaining processes.
Detaching DM devices
Could not delete dm /deb/dm-0: Device or resource busy
Not all DM devices deleted, 2 left
Cannot finalize remaining file systems and devices, giving up
[5172.191665] Restarting system
----------------------------------------------------------------------

That final statement doesn't occur of course. I have continually kept the system up-to-date - which means several new kernels - and no change to this behaviour.



Version-Release number of selected component (if applicable):


How reproducible:

always

Steps to Reproduce:
1. reboot or shutdown
2. wait
3. wait
  
Actual results:

no shutdown occurs


Expected results:


Additional info:

I don't think it's related, but please see another ticket I have in: 701176 - double-mounted partitions. I have since taken their advise and disabled sandbox - and indeed my double-mounted partitions disappeared. But the failing reboot issue remains

Comment 1 Jason Haar 2011-05-15 20:32:33 UTC
Forgot to add, this is a Dell Latitude E6320 laptop with a 250G SSD harddisk

Comment 2 Milan Broz 2011-05-16 13:00:16 UTC
There are two problems (and none is related directly to cryptsetup:)

1) the system need to have ability to decompose stacked device before restart/powerdown to correctly shut them off (here lvm over luks)

This was recently discussed and I think the solution is being worked on.
(See bug #681582 and others will probably follow.)

Anyway, if umount/deactivate fails, systemd will try to reboot anyway - apparently it here happens, but kernel refuses to do that.

So the 2) bug is that kernel is not able to reboot system - dmcrypt has no ability to block reboot, so this is probably some kernel regression elsewhere (or systemd do here something differently?)

Anyway, reassigning this to kernel after, this message
[5172.191665] Restarting system
clearly indicates reboot sequence started so it should correctly perform hw rebooot...

Comment 3 Christopher Hirschmann 2011-05-20 08:46:12 UTC
I had the same problem on a Dell Latitude E5420: fresh installation of F15 Beta with an encrypted physical volume for LVM that contains all filesystems exept /boot, only on my laptop shutdown worked, but reboot failed. I also had this problem with F14 previously (that's why I tried the F15 Beta, since my Latitude E5420 is a very recent model). I had the same problem with a Ubuntu 11.04 Live System booted from a stick.

I dug into the kernel documentation for this and found a workaround:

/usr/share/doc/kernel-doc-2.6.38.6/Documentation/kernel-parameters.txt:

reboot=         [BUGS=X86-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
                Format: <reboot_mode>[,<reboot_mode2>[,...]]
                See arch/*/kernel/reboot.c or arch/*/kernel/process.c

I took a look into that file (in the kernel SRPM) and apparently the kernel supports many different ways to initiate a reboot. I tried all that fit my architecture (some are only for x86_32, so I skipped those) and booting the kernel with the following parameter fixed it for me:

reboot=pci

Hope this workaround helps in finding the problem.

Comment 4 David A. De Graaf 2011-07-08 20:51:14 UTC
Eureka!   Christopher Hirschmann's trick of "reboot=pci" on the kernel boot line has allowed me to again  'reboot' on an IBM T30 laptop.  Without it, the laptop hangs and fails to reach the shutdown state.

Curiously, my other laptop - an ASUS N10 - reboots correctly without help.

Both laptops have four encrypted partitions for root, rootold, home and swap; but /boot is not encrypted.  On the IBM T30, only, I have to enter the passphrase twice.  But that's will be the subject of another BZ, after I've perused the rest of the systemd list - which is "too long for Red Hat Bugzilla's little mind".  :-)

Comment 5 Guido Avvisati 2011-11-07 12:37:45 UTC
I had the same issue on a DELL Precision M4600 laptop, but using Fedora 14 x86_64.

I found this issue reported in the common kernel problems page:
http://fedoraproject.org/wiki/Common_kernel_problems
where it says to set reboot=b kernel option. 

However, this did not work for me, while "Hirschmann's" option, reboot=pci, solved the problem for me as well.

Cheers,
Guido Avvisati

Comment 6 Josh Boyer 2012-06-06 12:59:39 UTC
Is this still a problem with the 2.6.43/3.3 kernel updates in F15/F16?

Comment 7 Josh Boyer 2012-07-11 17:52:19 UTC
Fedora 15 has reached it's end of life as of June 26, 2012.  As a result, we will not be fixing any remaining bugs found in Fedora 15.

In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with.  Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.

Thank you for taking the time to file a report.  We hope newer versions of Fedora suit your needs.