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

flashDeps: use buildPackages to fix cross-builds #201

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Princemachiavelli
Copy link
Contributor

Issue

Cross builds of nixosConfig containing an UEFI capsule update are currently broken due to how flashDeps are defined and used.

nix-repl> :b (nixosConfigurations.installer_minimal_cross.extendModules {
    hardware.nvidia-jetpack.enable = true; 
    modules = [{
      hardware.nvidia-jetpack.firmware.autoUpdate = true;
      hardware.nvidia-jetpack.som = "orin-nx";
     }];
}).config.system.build.toplevel

Results in exec format error due to wrong package set of flashDeps being used.

/build/.attr-0l2nkwhif96f51f4amnlf414lhl4rv9vh8iffyp431v6s28gsr90: line 24: /nix/store/g6s3cb7y0mmfa5i1s7xr5j9ma58rcwwn-coreutils-aarch64-unknown-linux-gnu-9.3/bin/cp: cannot execute binary file: Exec format error
/build/.attr-0l2nkwhif96f51f4amnlf414lhl4rv9vh8iffyp431v6s28gsr90: line 6: /nix/store/g6s3cb7y0mmfa5i1s7xr5j9ma58rcwwn-coreutils-aarch64-unknown-linux-gnu-9.3/bin/rm: cannot execute binary file: Exec format error
Changes

Use buildPackages for flashDeps so flash-script.nix uses the correct package set. As far as I can tell, there's no way to change which package set callPackage uses for passthru so directly using buildPackages seems like the best option.

The use of pkgs.buildPackages.callPackage is required for patchShebangs to set the correct interpreter in flash.sh. (Using callPackage for some reason just resulted in the shebang being left unmodified). There might be some other cause for this issue.

Testing

TODO

install -Dm0444 \
--target-directory=$(dirname $out/lib/firmware/${firmwarePath}) \
$(realpath ${pkgs.linux-firmware}/lib/firmware/${firmwarePath})
if [ -f ${pkgs.linux-firmware}/lib/firmware/${firmwarePath} ]; then
Copy link
Contributor

@jmbaur jmbaur Apr 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of the files in linux-firmware are symlinks, I don't think -f still works in that case. Can we also pull this change into a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, the change is just so I can test this PR. I intend to remove it.

@jmbaur
Copy link
Contributor

jmbaur commented Apr 1, 2024

The use of pkgs.buildPackages.callPackage is required for patchShebangs

Where does this patchShebangs happen? I can't find it

@Princemachiavelli
Copy link
Contributor Author

The use of pkgs.buildPackages.callPackage is required for patchShebangs

Where does this patchShebangs happen? I can't find it

I think it's added to the fixup in pkgs/build-support/setup-hooks/patch-shebangs.sh? I still don't understand why it's behavior would differ between pkgs.callPackage and pkgs.buildPackages unless the way it checks for build time commands fails if the architecture is different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants