lanzaboote_tool fails to build on current unstable #140
Labels
No labels
bug
dependency
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
review-next
security
stub
tool
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: raito/lanzaboote#140
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Same here, tracked it down to
TEST_SYSTEMD
, something is wrong withlib/systemd/boot/linuxx64.efi.stub
in systemd 253.@nikstur when you will be back, if you have time to look into this?
Possibly relevant observation: The build of
/nix/store/nhhd04plbhyv6akld7banyhnh34rj3z0-lanzaboote_tool-0.1.0.drv
seems to fail non-reproducibly. Here's the log of a successful build from my machine:nhhd04plbhyv6akld7banyhnh34rj3z0-lanzaboote_tool-0.1.0.drv_build_log.txt
Did you use the current nixos-unstable version? Try running
nix flake update
in the lanzaboote repo and test again.If I'm not mistaken, this shouldn't matter as long as the store hashes match.
It does matter, as lanzaboote relies on external tools and libraries provided by nixpkgs, some which has been updated since the nixpkgs version currently locked. But I am not quite sure why the output derivation does match for you.
EDIT: The tools that was updated is added in checkInputs and in a seperate wrapper derivation, so the main output derivation hash matching makes sense.
Here's the relevant parts from my system config
nix flake info
:i.e. I'm on the latest unstable and have pinned the lanzaboote nixpkgs input to my system nixpkgs-unstable. This results in the same store hash for
lanzaboote_tool
, which should ideally also result in identical build results across different machines due to the purity guarantees of Nix. However it doesn't, which indicates some sort of non-determinism like memory-related bugs in the build process.I also have this issue
Me too. Full log of test of failed test: