Dear Nix-ers,
I am currently encountering a problem with ukify when running: ukify genkey --secureboot-private-key /etc/secureboot/secure-boot-private-key.pam --secureboot-certificate /etc/secureboot/secure-boot-certificate.pam: ModuleNotFoundError: No module named cryptography. The problem is, that the cryptography module is not found alltough installed
environment.systemPackages = with pkgs; {
python3Full
python312Packages.cryptography
(python3.withPackages (p: with p; [
cryptography
]))
};
I executed this command in a freshly installed, zero times booted, with nixos-enter --root /mnt entered, luks-encrypted root partition nixos installation.
System has been build with flake and nixos-unstable.
systemdUkify isn’t actually going to be using the python environment you specify in environment.systemPackages (or anything from there). It’ll use the python environment specified in its own derivation, which is where the module would need to be included. So, this sounds to me more like either ukify itself is incorrectly installed, or a bug in nixpkgs. How did you install it?
So, the entry python312Packages.cryptography in environment.systemPackages does absolutely nothing.
The entry,
(python3.withPackages (p: with p; [
cryptography
]))
does add a python environment with the crpytography package to your PATH, but it’s entirely separate from the environment used by systemdUkify. So you only need it if you’re going to be using python with the cryptography package yourself.
I looked some more, and I think it’s a problem with the systemd package, and the cryptography library needs to be added here, but I’m not entirely sure. @flokli ?
That’s not how that override would work; withUkify is a boolean and kind of irrelevant here.
If you’re going to override it, just override at point-of-use, no need for overlays.
And you use overrideAttrs because there’s no expression arg to override, you’re overriding derivation args:
Hello ElvishJerricco,
I agree, this should be fixed upstream. Should I open a issue? Or create a pull request?
Anyways, I will leave this topic unsolved, until either a temporary fix is found or the package is patched upstream.
TBH, I’d struggle with that overlay, too. I’d probably find it easier to just fork nixpkgs, fix it in the fork, and then use that fork in my system. That’d also make is eaiser to send a PR upstream if the fix indeed works.