4

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.

Improve this question
4
  • This is hardly an answer, but if Fedora does that to you, maybe install a distro that doesn't? Commented Nov 26, 2016 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. Commented Nov 26, 2016 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. Commented Jan 2, 2018 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. Commented May 17, 2018 at 18:23

2 Answers 2

Reset to default
1

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.

Edit:

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.

Improve this answer
1

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.

Improve this answer

You must log in to answer this question.