systemd: build with cryptsetup support #62638
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <[email protected]>
…yptsetup-generator.c)
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)
ofborg
bot
added
6.topic: nixos
|
I'm not yet sure about the move of Do we want to change occurences of |
|
closing in favor of #66856. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation for this change
When building systemd with cryptsetup support, it knows how to read
/etc/crypttab(and generate on-the-fly units viacryptsetup-generator).This previously wasn't possible due to a dependency cycle, (systemd -> cryptsetup -> lvm2 -> udev=systemd).
Weird things like
systemd-cryptsetup-generatorandsystemd_with_lvm2started 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
sandboxinnix.confon non-NixOS)nix-shell -p nix-review --run "nix-review wip"./result/bin/)nix path-info -Sbefore and after)