Skip to content
This repository has been archived by the owner. It is now read-only.

LUKS password no-longer prompted on boot #1962

jpap opened this issue May 11, 2017 · 6 comments

LUKS password no-longer prompted on boot #1962

jpap opened this issue May 11, 2017 · 6 comments


Copy link

@jpap jpap commented May 11, 2017

Issue Report


I just manually upgraded a box from 1235.12.0 to 1353.7.0 and the LUKS password prompt for the root filesystem was no-longer being issued to the console on boot.

Extracting the initramfs on the 1353.7.0 vmlinuz image, it looks like:

  • The systemd-cryptsetup and systemd-cryptsetup-generator binaries are no-longer being included.
  • The has been removed.
  • The systemd-ask-password-console.path has been removed.

If I patch the 1353.7.0 initramfs with the above from 1235.12.0 (plus the old so the above cryptsetup binaries execute), the password prompt re-appears on boot.

Can we get the above systemd support back into the initramfs?

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
PRETTY_NAME="Container Linux by CoreOS 1353.7.0 (Ladybug)"


Bare metal server.

Expected Behavior

The LUKS password is prompted on boot from within the initramfs.

Actual Behavior

No prompt; dracut eventually times out and dumps the console on an emergency prompt.

Reproduction Steps

  1. Encrypt the root partition using LUKS.
  2. Boot.
  3. Try steps with 1235.12.0 (prompt -- works) and 1353.7.0 (no prompt -- broken).
Copy link

@euank euank commented May 11, 2017

AFAIK we've yet to intentionally support LUKS encrypting root, so the fact that it did work was merely a happy accident.

We're still working out proper support (more discussion #1687).

Since we're going to be shipping those tools in the initrd eventually regardless, it makes sense to add them back, but we might not have proper tests for this until we have a supported/documented approach using ignition.

cc @dm0-, it seems likely this changed as part of the v233 update at a guess.

Copy link

@jpap jpap commented May 11, 2017

I'm happy to have unofficial support until it is formalized. I've been making good use of LUKS for full-disk encryption since late 2016. I'm also happy to manually test it for you in the meantime, since I'm using it anyway.

To remotely supply the unlock secret on boot, I'm using a dropbear sshd. I do this by patching your initramfs for each CoreOS update, which is a pain, but I often have to rebuild kernel drivers (modules) on some upgrades anyway; this process is semi-automated.

Separately, would you be open to adding a dropbear sshd to the initramfs? I'm happy to open a new issue. In my setup, dropbear only activates when there exists a rd.luks.uuid kernel cmdline argument (added by Grub automatically) and when a dropbear.conf configuration file is present on the OEM partition. (It can also be explicitly disabled though rd.luks=false.) The dropbear {server, authorized-user} keys are supplied from the same OEM partition in a dropbear/ folder.

Copy link

@euank euank commented May 26, 2017

I'm wary of including dropbear. We're already pretty sure we'll want luks in the future, but it's less likely that we'll want dropbear in the long term.

Copy link

@jpap jpap commented May 26, 2017

I agree with that -- my approach was a pragmatic one. At this stage I'm not expecting dropbear support in the CoreOS initramfs. But it would be appreciated if you could restore cryptsetup in the meantime.

I can imagine that you'll eventually need some kind of client and daemon pair, with the initramfs acting as a client perhaps leading to a cleaner architecture. The initramfs connects on startup to a centralized daemon "waiting room" for their LUKS key. That key is provided either automatically, or manually on operator approval. You could use TLS mutual auth with client keys stored on the OEM partition; the server-side would need to support a CRL in case the CoreOS machine is stolen or compromised. Or, perhaps less desirable, we could use some kind of hardware ID in lieu of a client cert.

What I'm doing with dropbear/SSH is actually very similar to the above, where SSH keys are used in place of TLS mutual auth, and the initramfs is the daemon, not the client. The client is my terminal, where I manually SSH into the CoreOS machine (initramfs; via dropbear) after a reboot.

I'm not aware of anything we could use off-the-shelf. If I find any time, I'll have a stab at writing something simple -- would you be interested in that approach at all?

Copy link

@bgilbert bgilbert commented Jun 8, 2017

cryptsetup should be restored in 1437.0.0. I'll close this issue; design discussions for LUKS support should go in #1687. Thanks for the report!

@bgilbert bgilbert closed this Jun 8, 2017
Copy link

@lals1 lals1 commented Aug 31, 2017

@jpap Hi John, would you be kind enough to share details on how did you encrypt root filesystem using LUKS in CoreOS 1235.12.0? Would be a great help.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.