Shutdown hangs at "Stopping remaining crypto disks (busy)"
DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Shutdown hangs at "Stopping remaining crypto disks (busy)"
Hi, my question is basically the subject.
It is an up to date Debian testing amd64. It worked flawlessly until my last dist-upgrade some weeks ago. I'm using lvm+luks to encrypt all drives.
When shutting down, (w/o error messages), the last lines are:
Code:
[ ok ] Deactivating swap..done.
[ ok ] Unmounting local filesytems..done.
[....] Stopping remaining crypto disks...sdc5_crypt (busy)...
The systems hangs at this point, I need to kill it by long pressing the power button.
Can anyone give me some pointers how to debug this problem? So far, I could not find a log file which would give me useful information what's happening here.
The systems hangs at this point, I need to kill it by long pressing the power button.
While file systems are getting better all of the time and while I do understand your predicament you realize that still is an extremely ill advised thing to do, right?
Quote:
Originally Posted by fornax
Can anyone give me some pointers how to debug this problem?
There may be a process keeping files open during shutdown. The problem is you're way too far down the shutdown progress to have any terminal access available to diagnose things. I'd drop to (the equivalent of) runlevel 1 and see what processes are still running ('ps ax -eopid,args' should do) and then check open files with 'lsof -Pwlnp <pid>;' or just 'lsof -Pwln -a +D<mountpoint>;'.
You may have a terminal open, with a drive displayed. If you cd to a drive in a terminal, Linux won't allow you to unmount that drive, or do many other things with it. Something is certainly going on with the drive, but it's not possible to tell exactly from long distance.
Thanks for the answers so far. Of course I know that killing the system is a bad idea, but it really
hangs here (I've waited for several hours). So it unfortunately leaves me no choice.
I tried checking processes in single user but found nothing suspicious. I can post the output if you would like to have a look.
After more debugging, I found some other interesting issues.
To begin with, the upgrade (maybe since systemd, yay) renamed my disks.
Before the update, I had /dev/sdb1 -> sdb1_crypt and /dev/sdc5 -> sdc5_crypt.
Now, the disks got renamed to /dev/sda1 and /dev/sdb5.
Both still worked as they should with using UUIDs.
I adapted /etc/crypttab and /etc/blkid (new file? never saw that one before), shutdown
was successfull ONCE.
After that, I tried updating the initramfs, which gave me this warning:
Code:
cryptsetup: WARNING: invalid line in /etc/crypttab for sdc5_crypt -
The resulting initramfs did not boot and had no cryptsetup in the initramfs shell.
Had to fix it with a recovery shell from USB.
Now the names are correct, the problem stays the same except it is sdb5_crypt now.
If things work as they should using UUIDs, then why not use them and get on with life? You can't rely on drives being mounted as the same sd? every time. You could also give the drives labels, and mount using those labels, which is sometimes more reliable than UUID.
Okay, seems like my comments about the naming caused more uncertainties than they helped.
To bring it to the point: I was using UUIDs all the time, booting & mounting worked and still work, but *no* effect on the described problem.
The *one* time the system was shutting down was at one point after adapting the name (not the UUID!) in the crypttab. I could neither reproduce this, nor did it shut
down after rebooting with the "fixed" cryptab.
The whole naming thing was just something that I found quite interesting to cause problems (like the initrd/grub upgrade) at all. I thought it might be related. Turns out, it was not.
Distribution: Linux Mint 9, Linux Mint 17.2(xfce), LMDE2(Mate), Debian Jessie minimal (with standalone OBox)
Posts: 299
Rep:
Did your dist-upgrade also upgrade your kernel? If so, and if you still also have the old kernel, boot into it. Dist-upgrade to a new kernel caused the same problem with my hardware on Sid. Fortunately, i also had the original kernel 3.16 to boot into from which i flushed kernel 4.2.5. I have found that upgrading to a new kernel works without errors on my laptop only when i compile it from source while upgrading it from the repos or backports buggers up my system..more than once.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.