buildFHSUserEnv not supported on aarch64-darwin

Help
1

Can this be true? I have the following flake

{
  description = "fhs flake";
  
  inputs = {
    flake-utils.url = "github:numtide/flake-utils";
    nixpkgs.url = "nixpkgs/nixos-22.05";
  };
  
  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let

        pkgs = import nixpkgs { inherit system; };

        our-fhs = pkgs.buildFHSUserEnv {
          name = "our-fhs";
          targetPkgs = pkgs:
            (with pkgs; [
              binutils
            ]);
        };
                
      in rec {
        
        devShell =  pkgs.mkShell {
          buildInputs = [ pkgs.cowsay our-fhs ];
        };
      }
    );
}

for which nix develop returns

error: Package ‘chrootenv’ in /nix/store/xc6s7iccz5nkm8vl9nybz698nq2ngxlc-source/pkgs/build-support/build-fhs-userenv/chrootenv/default.nix:11 is not supported on ‘aarch64-darwin’, refusing to evaluate.

       a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

        Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
        (Flake) command, `--impure` must be passed in order to read this
        environment variable.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.
(use '--show-trace' to show detailed location information)
2

As far as I remember, FHS-env is only supported on *-linux, as *-darwin lacks the corresponding syscalls in the kernel.

3 Likes
3

Specifically, this syscall: https://github.com/NixOS/nixpkgs/blob/a36ceb869d7d5ffa1777cee9f1b2bf2027904b02/pkgs/build-support/build-fhs-userenv/chrootenv/src/chrootenv.c#L24

Mac OS might implement something similar, it’s probably not too incredibly difficult to add support if you’re a well-versed Mac OS developer.

4

It also lacks bind mounts, and unshare, and probably a number of other things.

5

Ah, fair enough, I see the use of namespaces now. I thought that would be exclusive to buildFHSUserEnvBubblewrap or whatever that was called.

I still have not actually tried it, but when I looked into this for another tool it seemed like it had equivalents for most things you need to create a useful chroot. It seems that there’s at least a bind mount hack through fuse: https://bindfs.org/

It would be interesting to see if a Mac OS implementation is feasible, even if not fully featured. In my mind chroot provides most of what you need for this, even if proper Linux namespaces are much nicer to use.

Not that I have the hardware to try myself, or much personal interest in non-Linux support. But I don’t think it’s entirely infeasible if there’s demand.

6

Would it make sense to use docker/podman to implement buildFhsUserEnv on macos for a quick alternative?

7

No. Those don’t run macOS binaries. They run Linux binaries in Linux VMs.

2 Likes
8

What do you need an FHSEnv for on macOS? They only really exist for NixOS because it doesn’t have an FHS. macOS OTOH always comes with a fully functional FHS.

2 Likes
9

First of all, thanks for discussing this everyone, it’s really great to interact with such an engaged community.

The reason I looked into using FHS on MacOS is because I have failed at getting some derivations to build on MacOS – deriviations that work fine on NixOS and Linux. See here for example. Motivated by this post and by the way I use Julia-lang under NixOS (as an FHS env) I thought, as a stop-gap measure, I would try ceding package/env management back to the R-lang environment management tool renv by using an FHS env.

I am definitely keen to hear thoughts, suggestions, opinions regarding this … situation.

10

Ah, I’ve never touched R packages.

I’d start by adding libtiff and sqlite to buildInputs of the sf derivation.

11

Can’t help much on R on MacOs (maybe create a separate question). But maybe providing a way to easily start a linux VM like nix-shell --linux-vm to compile stuff in MacOs could be a way to enforce more reproducibility on MacOs (as I understand MacOs changes some proprietary parts of its system that break reproducibility as tgey can’t be build by nix due to their proprietary nature).

12

Problem with that is that the products would only be usable inside a Linux VM too because you can’t build usable macOS binaries on Linux AFAIK.
There’s no point integrating guest controls into the Nix tools when you’d only be able to use the result in the guest anyways; might as well use the guest for development from the get-go.

13

Well this is true (even if some projects aim to bring this gap c++ - How to Compile for OS X in Linux or Windows? - Stack Overflow , I’m not sure they are legal) when you aim to output MacOs binaries. However sometimes the developper may just want to quickly compile a project without caring if the binary runs on MacOs or Linux (e.g. to quickly test a PR to a project), or outputs may not be binaries, for instance for R I guess that often people just want to produce reproductively (this is important for science) some graphs/pictures/database, in which case using a VM is cerlainly fine.

I agree that running a VM manually is certainly not to hard, but adding a flag in nix-shell that drops you directly in a VM vould be even simpler, and easier to reproduce.

1 Like
14

Hmmm, thanks, I think this could be pretty useful.