I'm installing Fedora 24 from scratch and writing it up at https://github.com/barrycarter/bcapps/blob/master/FEDORA/README

I've reinstalled many many times (and even tried CentOS 7 but gave up on it), but recently ran into a problem. When I do:

sudo systemctl start postgresql mysqld nagios dnsmasq httpd sendmail

(or even any of those individually, eg "sudo systemctl start nagios"), I get:

Please enter passphrase for disk STxxxxxx-xxxxxx (luks)! *

The problem: I already entered my disk password at boot time, and confirmed both my main install drive (an SSD) an my other hard drive are up and running just fine. There's no need to ask for the luks password again!

I can obviously work around this by running these commands "manually" later, but this seems glitchy. Is there a fix? Have I done something wrong?

NOTE: I realize my disk number is probably not private, but I elided it anyway.

  • This is hardly an answer, but if Fedora does that to you, maybe install a distro that doesn't? Nov 26 '16 at 4:54
  • I'm actually "upgrading" from Fedora Core 11, so I thought Fedora would be the best path. I also tried Linux Mint and CentOS, but both of them bring up too much crap. If you know of a truly minimal, but still up-to-date distribution with decent distros, do let me know.
    – user2267
    Nov 26 '16 at 19:33
  • Was there ever an update on this? I have similar behaivor now on starting a oneshot service that just runs a few find ... -execdir ... commands and doesn't actually reference the encrypted disk at all. Jan 2 '18 at 4:34
  • A year and a half later... but Ubuntu does the same thing. I think it's a general systemctl issue, which means it will affect most mainstream distros.
    – Dav Clark
    May 17 '18 at 18:23

I think I've found part of the answer to this question.

Here's the situation. Since the last time I rebooted my system, I umount'd, and cryptsetup luksClose'd an encrypted volume. I also commented out its line in /etc/crypttab and changed its line in /etc/fstab to noauto.

Later, I run sudo systemctl start my-oneshot and (I'm guessing) systemd notices that one of the filesystems it generated a unit for is no longer mounted, so it tries to start systemd-cryptsetup@volumename_unlk.service which, for some reason, doesn't use the mapped name "volumename_unlk" but instead uses "temporary-cryptsetup-1234" or some other 4-digit number.

As a result, the unit fails and tries to restart the next time I try to run systemctl start my-oneshot and continues to ask for the password.

Am I still confused? Yes. But at least some clarity has been brought. I suspect a reboot will solve this problem by allowing systemd to regenerate its units for crypto devices and mountpoints. I'll update here when I have a chance to reboot.


Yep, after a reboot, the offending cryptsetup unit is no longer present and I don't get asked my password when starting my oneshot unit.


The command for solving these kind of situations without a reboot is

systemctl daemon-reload

Not only will it reload all unit files in case you've made changes to them, it will also re-run all unit generators. And that is exactly what you want after making changes to /etc/crypttab and/or /etc/fstab.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy