Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd: build with cryptsetup support #62638

Closed
wants to merge 6 commits into from

Conversation

@flokli
Copy link
Contributor

flokli commented Jun 3, 2019

Motivation for this change

When building systemd with cryptsetup support, it knows how to read /etc/crypttab (and generate on-the-fly units via cryptsetup-generator).

This previously wasn't possible due to a dependency cycle, (systemd -> cryptsetup -> lvm2 -> udev=systemd).

Weird things like systemd-cryptsetup-generator and systemd_with_lvm2 started popping up, which worked in some cases, but in a very unintuitive fashion.

We can simply solve the depencency cycle by passing to the systemd build a version of (lib)cryptsetup that was built with an lvm that was built without udev support. (Which should still work, given to how systemd uses libcryptsetup).

That way, we can slowly add native crypttab support into NixOS, working towards fixing things like #62211 in a more generic fashion.

This is still WIP, due to the move of udev to aliases.nix, missing changelog entries and me not having fully tested this. Feedback very welcome :-)

cc @d3rped @petabyteboy

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

flokli and others added 6 commits May 13, 2019
We have to break the dependency chain mentioned in
b06cb35.
(systemd -> cryptsetup -> lvm2 -> udev=systemd)

We do this by updating the lvm2 derivation to build without udev, so we
can give systemd a (lib)cryptsetup it can link against. We still need to
check whether this is enough, or if lvm needs to be bootstraped by a
udev/systemd which does not yet contain cryptsetup support - hopefully
not.

While working on the lvm2 derivation, the following cleanups where done
in the lvm2 derivation:
 - set installFlags directly, instead of doing it inside a script in
   preInstall
 - use installTargets again ("install", plus
   "install_systemd_{generators,units,configuration}" when udev is not
   null)
 - The call to the blkid binary in lvm2's 13-dm-disk.rules file
   disappeared (so we don't need to patch in blkid anymore).
   lvm seems to rely on udev's internal blkid functionality.
 - Call /run/current-system/systemd/bin/udevadm instead
   of ${systemd}/bin/udevadm in the lvm activation generator.
   This is not necessary to break the dependency cycle (as we don't use
   that file when building wihtout udev), but a good idea anyways -
   We want to trigger the udevadm of the current system, not the one
   that lvm was built with.
 - Remove the unused purity.patch

Co-Authored-By: Arian van Putten <aeroboy94@gmail.com>
This package previously did override the systemd package, and instructed
ninja, systemd's previous build system, to only build the
cryptsetup-specific systemd generators (plus some rpath massaging, as we
didn't use ninja install).

Afterwards, users were expected to add this package to their
`systemd.generator-packages` NixOS module options, so systemd will use
these generators.

As the previous commit added cryptsetup support directly to the systemd
package (and pkgs.systemd now already ships the cryptsetup generators),
we don't need another package shipping the same generators.

So we remove the custom derivation. It might be possible to alias the
attribute to `systemd`, as adding systemd's generators to the list of
used generators should be a no-op, but it's cleaner to prompt users to
update their configuration.
Instead, prompt user to add it to systemd.system-generators, which is a
cleaner way, and we don't need to rebuild the world by changing systemd
globally.

Initially introduced in c0fd887.
We might want to do this conditionally on whether lvm is enabled (or add
the lvm system-generators unconditionally, too)
@flokli flokli requested review from Mic92, lheckemann, andir and c0bw3b Jun 3, 2019
@flokli flokli added this to To Do in systemd via automation Jun 3, 2019
@flokli
Copy link
Contributor Author

flokli commented Jun 3, 2019

I'm not yet sure about the move of udev to aliases.nix - there's a lot of packages currently using udev (and hopefully only things from the udev and libudev targets) - do we want to have a separate package for just udev and libudev?

Do we want to change occurences of {systemd}/bin/udevadm or {udev}/bin/udevadm to /run/current-system/systemd/bin/udevadm?

@flokli flokli requested a review from Profpatsch Jun 4, 2019
@flokli
Copy link
Contributor Author

flokli commented May 4, 2020

closing in favor of #66856.

@flokli flokli closed this May 4, 2020
@flokli flokli moved this from To Do to Done in systemd May 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
systemd
  
Done
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.