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

deploy from darwin to nixos and vice versa #216

Open
happysalada opened this issue May 21, 2023 · 13 comments
Open

deploy from darwin to nixos and vice versa #216

happysalada opened this issue May 21, 2023 · 13 comments

Comments

@happysalada
Copy link

Remote builds have been implemented, but trying to deploy a nixos flake from a darwin machine complains

error: a 'x86_64-linux' with features {} is required to build '/nix/store/b1ajwc4fb2zj6pr0hkbdv1cjx4kxf75s-default-conf.json.drv', but I am a 'x86_64-darwin' with features {benchmark, big-parallel, nixos-test}

it would be nice to be able to do the build process completely remotely so as to do os hybrid deployments.
(I thought I would open another issue since the remote-build feature doesn't solve this use case).

@rvem
Copy link
Member

rvem commented May 22, 2023

Hmm, x86_64-linux deployments to x86_64-darwin work for me with --remote-build.
I didn't really try to deploy anything the other way around 🤔

@rvem
Copy link
Member

rvem commented May 22, 2023

Does your profile use IFD by any chance?

@happysalada
Copy link
Author

no It doesn't.
here is my flake https://github.com/happysalada/dotfiles
I'm deploying the "bee" profile.
For that my only way to deploy is to use nixinate for now.
I've just double checked with a --no-allow-import-from-derivation to be sure, and I still managed to deploy.

@eliandoran
Copy link

eliandoran commented Jul 2, 2023

@happysalada , on my side I was able to deploy from a x86_64-darwin to a x86_64-linux by skipping checks

deploy --remote-build --skip-checks .#foo

Obviously it's not a good idea to deploy without checks, but it's a good starting point.

@happysalada
Copy link
Author

Nice ! I thought i had tried without checks, i must have just imagined it.
Im going to give this another go in 6 months time.

@bachrc
Copy link

bachrc commented Nov 30, 2023

Bumping this as I am facing the same kind of issue right now. Skipping checks helped!

@rbreslow
Copy link

This also happens to me!

error: a 'x86_64-linux' with features {} is required to build '/nix/store/88r7cxcy27fhsysc7fzrwhlfc4vpxr2c-builder.pl.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}

@JeanMertz
Copy link

See also: #167 (comment)

The problem is that deployChecks runs locally, even if --remote-build is provided. So if your deploy target's architecture differs from your local machine's, it won't work, until checks are rewritten to run remotely as well.

@tcurdt
Copy link

tcurdt commented Mar 16, 2024

I don't get this working - at all.

  outputs =
    { self
    , deploy-rs
    , ...
    } @ inputs:
    {
      # ...

      deploy.nodes.utm = {
        hostname = "192.168.71.3";
        remoteBuild = true;
        profiles.system = {
          user = "root";
          path = deploy-rs.lib.aarch64-linux.activate.nixos self.nixosConfigurations.utm;
        };
      };
      # checks = builtins.mapAttrs (system: deployLib: deployLib.deployChecks self.deploy) deploy-rs.lib;
    }

I had to disable the checks - but I am still getting a warning

$ nix flake check --show-trace
warning: unknown flake output 'deploy'

What am I missing?

@tcurdt
Copy link

tcurdt commented Mar 16, 2024

Hm. Seems to work anyway.

$ nix run github:serokell/deploy-rs .
🚀 ℹ️ [deploy] [INFO] Running checks for flake in .
warning: unknown flake output 'deploy'
🚀 ℹ️ [deploy] [INFO] Evaluating flake in .
🚀 ℹ️ [deploy] [INFO] The following profiles are going to be deployed:
[utm.system]
user = "root"
ssh_user = "tcurdt"
path = "/nix/store/z2nsrr89fsjap88b6vpdy3ziwrpicqqs-activatable-nixos-system-nixos-24.05.20240314.d691274"
hostname = "192.168.71.3"
ssh_opts = []

🚀 ℹ️ [deploy] [INFO] Building profile `system` for node `utm` on remote host
🚀 ℹ️ [deploy] [INFO] Activating profile `system` for node `utm`
🚀 ℹ️ [deploy] [INFO] Creating activation waiter
⭐ ℹ️ [activate] [INFO] Activating profile
👀 ℹ️ [wait] [INFO] Waiting for confirmation event...
updating GRUB 2 menu...
activating the configuration...
setting up /etc...
reloading user units for root...
reloading user units for tcurdt...
restarting sysinit-reactivation.target
⭐ ℹ️ [activate] [INFO] Activation succeeded!
⭐ ℹ️ [activate] [INFO] Magic rollback is enabled, setting up confirmation hook...
👀 ℹ️ [wait] [INFO] Found canary file, done waiting!
⭐ ℹ️ [activate] [INFO] Waiting for confirmation event...
🚀 ℹ️ [deploy] [INFO] Success activating, attempting to confirm activation
🚀 ℹ️ [deploy] [INFO] Deployment confirmed.

@rvem
Copy link
Member

rvem commented Mar 18, 2024

I had to disable the checks - but I am still getting a warning

The warning is somewhat expected since deploy-rs expects deploy flake outputs that aren't "standard" flake outputs and thus nix emits a warning during the evaluation

@tcurdt
Copy link

tcurdt commented Mar 18, 2024

I had to disable the checks

I suspect there are no tangible plans to support this scenario?

So if your deploy target's architecture differs from your local machine's, it won't work, until checks are rewritten to run remotely as well

The warning is somewhat expected since deploy-rs expects deploy flake outputs that aren't "standard" flake outputs and thus nix emits a warning during the evaluation

I see. And there is no way for nix to accept the output as expected?

@PhilTaken
Copy link
Collaborator

PhilTaken commented Mar 18, 2024

I suspect there are no tangible plans to support this scenario?

there is no way currently to run checks remotely and running darwin checks on a linux machine is quite the endeavour.
we could possibly implement a check that emulates what nix does but runs it remotely, however the introduced complexity would be significant compared to using magic-rollback for these cases

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

No branches or pull requests

8 participants