I have 72 cores I would like to use.

I'm very much in favor of enabling this sort of usage!! However for something as absolutely critical as coreutils, I'm reluctant to disable so many tests. On one hand, AFAIK we've never had a problem with coreutils that a)was a build env/configuration problem and not just the fallout of intentional coreutils behavior change across version, AND/OR b)tests would have caught. On the other hand, we really don't want avoidable problems in these tools.

• Disabling it (somehow?) only on such environments: similar (but less widespread) risks, and I expect would break hashes? Which is unfortunate, although I'm given the impression HPC users often require/prefer alternative NIX_STORE paths anyway.
• Can an appropriate sandbox be created for this? Execution in QEMU?

I'm not entirely against this if we can't find other solutions, but seems worth at least brainstorming other ways first :).

Follow-up: is there a way to test this-- either to avoid regressions in the future once it's fixed, or more immediately to explore alternatives? :)

Changing the /nix prefix is not required when the host system supports usernamespaces, which is what I do here. This works on debian and ubuntu-based systems.

• Breaking the hash is what I want to avoid, since I want to use the these machines for testing nixpkgs/cross-compilation.
• Disabling those tests conditionally will result in bit-rot when coreutils is upgraded
• Execution in qemu requires access to /dev/kvm to get decent performance, which is not the default on most linux distribution

I updated the test list. Now it is only 5 out of 600 tests for coreutils that are disabled and are all related to chgrp, where the problem is that only one of the two groups in the sandbox are usable by the build user and 3 tests in gnulib, also related to ownership. If we would ever have a problem with those very basic commands, where are likely to catch this in other packages/nixos tests.

Does this sound acceptable?