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

cryptsetup: Build with an lvm2 that’s built with udev #97002

Closed
wants to merge 1 commit into from

Conversation

andersk
Copy link
Contributor

@andersk andersk commented Sep 3, 2020

Motivation for this change

Apparently, taking one more step along the systemd → cryptsetup → lvm2 → udev=systemd dependency cycle before breaking the chain allows the installer.luksroot test to pass.

This is a bit ridiculous because we end up with this even stupider chain in the runtime closure of lvm2:

lvm2 → systemd → cryptsetup → different lvm2 → different systemd

But it’s better than leaving nixos-unstable blocked forever while we look for a better solution. Fixes #96479.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • 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 nixpkgs-review --run "nixpkgs-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)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

Apparently, taking one more step along the systemd → cryptsetup → lvm2 →
udev=systemd dependency cycle before breaking the chain allows the
installer.luksroot test to pass.

This is a bit ridiculous because we end up with this even stupider chain
in the runtime closure of lvm2:

lvm2 → systemd → cryptsetup → different lvm2 → different systemd

But it’s better than leaving nixos-unstable blocked forever while we
look for a better solution.  Fixes NixOS#96479.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
@arianvp
Copy link
Member

arianvp commented Sep 3, 2020

@GrahamcOfBorg test installer.luksroot

@arianvp
Copy link
Member

arianvp commented Sep 3, 2020

@GrahamcOfBorg test installer.luksroot

(Again; nix-build threw some internal error)

@arianvp
Copy link
Member

arianvp commented Sep 3, 2020

As borg isn't working; i'm running the test now locally (on nixbuild). Once the test is green on my box I'll merge!

@andersk
Copy link
Contributor Author

andersk commented Sep 3, 2020

This slightly less convoluted alternative patch, which breaks the cycle at the same inner point but builds one fewer outer lvm2, also passes installer.luksformat. It’s reasonably fast to test if you’ve already built the first patch, since its systemd and cryptsetup are the same.

--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -17234,11 +17234,7 @@ in
 
   criu = callPackage ../os-specific/linux/criu { };
 
-  cryptsetup = callPackage ../os-specific/linux/cryptsetup {
-    # cryptsetup only really needs the devmapper component of cryptsetup
-    # but itself is used as a library in systemd (=udev)
-    lvm2 = lvm2.override { udev = null; };
-  };
+  cryptsetup = callPackage ../os-specific/linux/cryptsetup { };
 
   cramfsprogs = callPackage ../os-specific/linux/cramfsprogs { };
 
@@ -17994,7 +17990,12 @@ in
 
   lsscsi = callPackage ../os-specific/linux/lsscsi { };
 
-  lvm2 = callPackage ../os-specific/linux/lvm2 { };
+  lvm2 = callPackage ../os-specific/linux/lvm2 {
+    # udev is the same package as systemd which depends on cryptsetup
+    # which depends on lvm2 again.  But we only need the libudev part
+    # which does not depend on cryptsetup.
+    udev = udev.override { cryptsetup = null; };
+  };
   lvm2_dmeventd = callPackage ../os-specific/linux/lvm2 {
     enableDmeventd = true;
     enableCmdlib = true;

@andersk
Copy link
Contributor Author

andersk commented Sep 3, 2020

Submitted this alternative as #97008.

@andersk
Copy link
Contributor Author

andersk commented Sep 3, 2020

Closing in favor of #97008 (we can reopen if someone disagrees).

@andersk andersk closed this Sep 3, 2020
@andersk andersk deleted the cryptception branch December 26, 2022 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants