5 ms·

Systemd-cryptsetup: Booting with encrypted root partition fails instantly

58 points by noch 9y ago

kawsper 9y ago
I wonder how elaborate their automated tests are, it is also quite interesting that the provided fix did not introduce any new tests to the codebase for the reported case.
- andrewstuart2 9y ago
  Poettering does mention that the tests do not cover LUKS boots, and I would hope they will be adding some in the near future, but I also understand that the priority would be fix first, automated tests second (hopefully), since this is already out in the wild and in need of a fix. Agreed, though, that full-disk encryption is common (and important) enough that it should merit good automated regression testing, especially simple "does it still boot?" tests.
  - hobarrera 9y ago
    I was actually amazed they don't test this scenario (I was one of first affected by this bug on all my systems about a week ago). LUKS encryption is probably THE most common setup for newer desktop linux installations, so I was amazed they didn't test this, but just rather plain ol' unencrypted setups.
    - johnny22 9y ago
      Does any popular distro enable it by default?
      - bmn__ 9y ago
        That's the wrong question, it does not matter what the default value in the distro installer partitioning step is. What matters is that LUKS (often labelled as full-disk encryption or similar) is easily available at install time, and consequently enjoys popular adoption and use.
djsumdog 9y ago
Looks like one of the people on the thread is using Gentoo, which is one of the few distributions that offers a choice between systemd and openrc. I currently use LUKS for full disk encryption (including /boot) on Gentoo (openrc) with Grub doing the luks unlocking (my initrd has to unlock the encrypted partition too/again, but I just have a key saved within the initrd so I don't have to type the password twice).
- geofft 9y ago
  It sounds from the thread like Arch gives you a choice between systemd handling cryptsetup and using the older cryptsetup implementation (using shell scripts?). If I remember correctly, systemd's native support for cryptsetup is relatively new and largely modeled on Debian's extensive integration, which worked well with systemd before the native support showed up.
  - hobarrera 9y ago
    No; systemd handling encrypted boot isn't new. I moved to using it over a year ago, and it was already quite spread within the Arch community (from the amount of forum posts, etc at the time), so it's probably quite older than that.
- infinisil 9y ago
  What do you think is the benefit of encrypting /boot? I can't imagine having anything sensible on there.
  - TylerE 9y ago
    I would imagine it's more about making sure no one ELSE can drop a payload in there... e.g. a backdoor'ed kernel.
    - Rjevski 9y ago
      Secure Boot should be able to defend against that if you take the time to set it up (you'd need to enroll your own key in the system firmware and then sign your kernel with that key).
Rjevski 9y ago
Curious to see this making the front page of HN - what's so special about this bug?
- emeraldd 9y ago
  It has two "hot" issues in it: - System won't boot - Systemd The first is enough to catch a large number of people's attention and the second is usually enough to start a bit of a flame war.
- tyingq 9y ago
  Probably the historical animosity around systemd from those that feel it has scope creeped into places it doesn't belong.
  - johnny22 9y ago
    I don't know where they got that idea. This was almost always in scope by design, if not yet in implementation (at the time)
throwawaymanbot 9y ago
I'm convinced that this systemd thing, is but a bad joke, played on us all. Hysterical. Any chance Red Hat can put Mr. Poettering away somewhere?, like away where he can work on something else? Pure farce.
- chris_wot 9y ago
  There's really no need to be so nasty and make personal attacks against Poettering. Please don't register a throwaway account just to throw shade, it doesn't show much class or courage.
  - throwawaymanbot 9y ago
    Ha! Poor little Lenny. Although it says throwaway in the username, its not actually a throwaway. Just in the same way if it said poetteringsego in the username, it would not actually be poetterings ego. Ya savvy?
- fooker 9y ago
  If your bugs make the HN frontpage, you must be doing something right and useful.
jvoorhis 9y ago
Two distros referenced on this thread are Gentoo and Arch - both are rolling-release tinkerer's distros, and it has been noted that the feature in question has been out of scope for QA by the systemd project as of late. The community quickly found and shared workarounds and the bug will get fixed. I was bitten by this bug, but I'm not sweating it.

58 points by noch 9y ago

I wonder how elaborate their automated tests are, it is also quite interesting that the provided fix did not introduce any new tests to the codebase for the reported case.

andrewstuart2 9y ago
Poettering does mention that the tests do not cover LUKS boots, and I would hope they will be adding some in the near future, but I also understand that the priority would be fix first, automated tests second (hopefully), since this is already out in the wild and in need of a fix. Agreed, though, that full-disk encryption is common (and important) enough that it should merit good automated regression testing, especially simple "does it still boot?" tests.
- hobarrera 9y ago
  I was actually amazed they don't test this scenario (I was one of first affected by this bug on all my systems about a week ago). LUKS encryption is probably THE most common setup for newer desktop linux installations, so I was amazed they didn't test this, but just rather plain ol' unencrypted setups.
  - johnny22 9y ago
    Does any popular distro enable it by default?
    - bmn__ 9y ago
      That's the wrong question, it does not matter what the default value in the distro installer partitioning step is. What matters is that LUKS (often labelled as full-disk encryption or similar) is easily available at install time, and consequently enjoys popular adoption and use.

djsumdog 9y ago

Looks like one of the people on the thread is using Gentoo, which is one of the few distributions that offers a choice between systemd and openrc. I currently use LUKS for full disk encryption (including /boot) on Gentoo (openrc) with Grub doing the luks unlocking (my initrd has to unlock the encrypted partition too/again, but I just have a key saved within the initrd so I don't have to type the password twice).

geofft 9y ago
It sounds from the thread like Arch gives you a choice between systemd handling cryptsetup and using the older cryptsetup implementation (using shell scripts?). If I remember correctly, systemd's native support for cryptsetup is relatively new and largely modeled on Debian's extensive integration, which worked well with systemd before the native support showed up.
- hobarrera 9y ago
  No; systemd handling encrypted boot isn't new. I moved to using it over a year ago, and it was already quite spread within the Arch community (from the amount of forum posts, etc at the time), so it's probably quite older than that.
infinisil 9y ago
What do you think is the benefit of encrypting /boot? I can't imagine having anything sensible on there.
- TylerE 9y ago
  I would imagine it's more about making sure no one ELSE can drop a payload in there... e.g. a backdoor'ed kernel.
  - Rjevski 9y ago
    Secure Boot should be able to defend against that if you take the time to set it up (you'd need to enroll your own key in the system firmware and then sign your kernel with that key).

Rjevski 9y ago

Curious to see this making the front page of HN - what's so special about this bug?

emeraldd 9y ago
It has two "hot" issues in it: - System won't boot - Systemd The first is enough to catch a large number of people's attention and the second is usually enough to start a bit of a flame war.
tyingq 9y ago
Probably the historical animosity around systemd from those that feel it has scope creeped into places it doesn't belong.
- johnny22 9y ago
  I don't know where they got that idea. This was almost always in scope by design, if not yet in implementation (at the time)

throwawaymanbot 9y ago

I'm convinced that this systemd thing, is but a bad joke, played on us all. Hysterical. Any chance Red Hat can put Mr. Poettering away somewhere?, like away where he can work on something else? Pure farce.

chris_wot 9y ago
There's really no need to be so nasty and make personal attacks against Poettering. Please don't register a throwaway account just to throw shade, it doesn't show much class or courage.
- throwawaymanbot 9y ago
  Ha! Poor little Lenny. Although it says throwaway in the username, its not actually a throwaway. Just in the same way if it said poetteringsego in the username, it would not actually be poetterings ego. Ya savvy?
fooker 9y ago
If your bugs make the HN frontpage, you must be doing something right and useful.

jvoorhis 9y ago

Two distros referenced on this thread are Gentoo and Arch - both are rolling-release tinkerer's distros, and it has been noted that the feature in question has been out of scope for QA by the systemd project as of late. The community quickly found and shared workarounds and the bug will get fixed. I was bitten by this bug, but I'm not sweating it.