nixos/stub-ld: init module

[tejing1]

Description of changes

Adds a new nixos option, enabled by default, which installs a stub ELF loader in the default FHS location. This stub simply prints out an informative error message when invoked, giving new users better feedback when they attempt to use binaries not compiled for nixos.

Closes #208187.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

Priorities

Add a 👍 reaction to pull requests you find important.

[tejing1]

Should the message be shorter, with a link to a more in-depth discussion online, perhaps in the nixos manual?

Should I mention nix-autobahn and/or nix-alien?

[mkg20001]

Should I mention nix-autobahn and/or nix-alien?

Not sure, are these common tools one would use? (As in: Is the tool known and used by many or is it just "one of many tools available")

One sentence saying something about these tools being available might be good.

Should the message be shorter, with a link to a more in-depth discussion online, perhaps in the nixos manual?

I would move parts about packaging to the manual and just link to a new section in the manual. And from that section link to the relevant parts of packaging. Since packaging is usually more complicated then "just run this".

2. Write a nix expression for the program to package it
         yourself. Read more in the manual <link>

[tejing1]

Hmm, should I add a new section to the nixpkgs manual? Or perhaps just link to https://nix.dev/tutorials/packaging-existing-software?

[tejing1]

I honestly don't feel like the manuals are quite the right place for this to exist. It's more introductory content than reference content. It needs to be somewhere, though. Right now, afaik, there just isn't a resource which clearly lays out the options one has when trying to run software on nixos that isn't in nixpkgs.

@NixOS/documentation-team may want to weigh in here.

Where should this live?

[tejing1]

@Mic92 As the maintainer of nix-ld, any comments on adding libDir to the platform attrset, how this interacts with nix-ld, or how this is implemented, generally? Should I change the nix-ld module(EDIT: package) to use libDir in this PR as well?

[fricklerhandwerk]

This is indeed a good topic for a guide on nix.dev. Probably doesn't need to be much more than that if there is reference documentation one can link to.

It's not really NixOS specific, and only needs a note on NixOS with links to the relevant options.

[Mic92]

@tejing1 we already have a chapter about fhs in the works here: #264433 hopefully merged soon.

[tazjin]

For $reasons I'm setting this stuff up in activation scripts on work machines, and trying to fit that back into derivations is going to be messy. Frankly I just don't have the time or motivation for these kinds of changes at the moment, so I'm reverting my nixpkgs for now.

For what it's worth, disabling this via disabledModules also doesn't work easily, because options related to the ldso module are used outside of it.

I understand the motivation behind this and it's of course a good idea to make an easy declarative setup available for simple use-cases, but - as is my usual criticism - things like this should always provide an escape hatch.

[tejing1]

The simplest solution would probably be to disable ldso.nix with disabledModules, then add a module that creates dummy environment.ldso and environment.ldso32 options to quiet the errors.

[tejing1]

This seems to work fine:

{ lib, modulesPath, ... }:
{
  disabledModules = [ (modulesPath + "/config/ldso.nix") ];
  options.environment.ldso = lib.mkOption { type = lib.types.unspecified; };
  options.environment.ldso32 = lib.mkOption { type = lib.types.unspecified; };
}

[yu-re-ka]

I must unfortunately say that the assumption that there exists a working 32bit variant of the package set for 64-bit x86 systems is inaccurate.
There should be an option to disable the 32-bit ldso even when running on x86-64 systems.

[tejing1]

There should be an option to disable the 32-bit ldso even when running on x86-64 systems.

There is. environment.ldso32 = null;

[yu-re-ka]

There is. environment.ldso32 = null;

That still evaluates pkgsi686Linux via libDir32 in the tmpfiles rules.

[tejing1]

Ugh. I'm not sure it's feasible to make that option such that the module cleans up after itself when the option is changed.

How about this:

• Add a pair of options to control the path of ld.so used, which default to /${libDir}/${ldsoBasename} we're currently using.
• Make those options nullable, and if they are null, produce no tmpfiles rule at all.
• Make those options hidden, as they should be very rarely used and have the annoying caveat that altering them leaves mess behind, which we can also note in the description.

[tejing1]

Oh! Here's another idea: switch the module to using systemd.tmpfiles.settings, so you can use lib.mkForce to remove the rules, if desired.

[yu-re-ka]

Or, generalize the isx86 check into some kind of tryEval magic to figure out if the 32-bit platform is actually supported?

for reference:

$ nix repl --system aarch64-linux
nix-repl> pkgsi686Linux
error:
       … while evaluating the attribute 'pkgsi686Linux'

         at /home/yuka/proj/nixpkgs/pkgs/top-level/stage.nix:222:5:

          221|     # Used by wine, firefox with debugging version of Flash, ...
          222|     pkgsi686Linux = if stdenv.hostPlatform.isLinux && stdenv.hostPlatform.isx86 then nixpkgsFun {
             |     ^
          223|       overlays = [ (self': super': {

       … while calling the 'throw' builtin

         at /home/yuka/proj/nixpkgs/pkgs/top-level/stage.nix:232:12:

          231|       };
          232|     } else throw "i686 Linux package set can only be used with the x86 family.";
             |            ^
          233|

       error: i686 Linux package set can only be used with the x86 family.

nix-repl> 

$ nix repl --system x86_64-linux
nix-repl> pkgsMusl.pkgsi686Linux 
error:
       … while evaluating the attribute 'pkgsi686Linux'

         at /home/yuka/proj/nixpkgs/pkgs/top-level/stage.nix:222:5:

          221|     # Used by wine, firefox with debugging version of Flash, ...
          222|     pkgsi686Linux = if stdenv.hostPlatform.isLinux && stdenv.hostPlatform.isx86 then nixpkgsFun {
             |     ^
          223|       overlays = [ (self': super': {

       … while evaluating a branch condition

         at /home/yuka/proj/nixpkgs/pkgs/stdenv/booter.nix:99:7:

           98|     thisStage =
           99|       if args.__raw or false
             |       ^
          100|       then args'

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: unsupported platform for the pure Linux stdenv

nix-repl> 

[zimbatm]

It feels like the design is still being fleshed out.

Given how core the change is, that it's blocking many users, and that it has been two months, we should consider reverting. Not permanently, but that way, you have time to figure this out while also not blocking other users.