Update build/quick start instructions

[knuton]

The quick start instructions were actually more like "slow start" instructions, suggesting to do a full build. Even worse, nix build fails in modern versions of the Nix CLI, which expects to find a flake file with this invocation.

This suggests to use the commonly used ./build script instead and updates it to provide a minimal bit of guidance when invoking it empty (instead of doing, again, the full build).

A full build can still be done by invoking ./build all.

For @yfyf.

Checklist

• Changelog updated
• Code documented
• User manual updated

[yfyf]

This is great, though nix-build / ./build all fails for me with:

error:
       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:9:12:
            8|
            9|   strict = derivationStrict drvAttrs;
             |            ^
           10|

       … while evaluating derivation 'playos-2024.7.0-VALIDATION'
         whose name attribute is located at /nix/store/27rg15w6bjjh2hkbdqajhvqd7b02v5cb-source/pkgs/stdenv/generic/make-derivation.nix:348:7

       … while evaluating attribute 'buildCommand' of derivation 'playos-2024.7.0-VALIDATION'
         at /home/yfyf/src/dividat/playos/default.nix:102:3:
          101|
          102|   buildCommand = ''
             |   ^
          103|     mkdir -p $out

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

       error: The option `programs.activationScripts' does not exist. Definition values:
       - In `/nix/store/27rg15w6bjjh2hkbdqajhvqd7b02v5cb-source/nixos/modules/services/x11/desktop-managers/cde.nix':
           {
             _type = "if";
             condition = false;
             content = {
               setup-cde = ''
           ...

[knuton]

Odd, I do not get this.

Maybe related to running the build on a non-NixOS system somehow?

I pushed a commit to let the CI runner do a ./build all, and it has the same issue you report: https://github.com/dividat/playos/actions/runs/10075744434/job/27854644214?pr=170

[knuton]

Maybe you could check which of these args may be true for the build to work on your system? (By "work" I mean "not fail immediately during evaluation" for now.)

playos/default.nix

Lines 20 to 23 in 95cd09b

	, buildInstaller ? true
	, buildBundle ? true
	, buildDisk ? true
	, buildLive ? true

nix-build --arg buildInstaller false --arg buildBundle false --arg buildLive false --arg buildDisk true etc. (this particular combination segfaults on GitHub's Ubuntu runner which is ... interesting)

[yfyf]

The culprit seems to be buildDisk - settings to true causes the build to fail, though it throws a different error than nix-build:

$ export NIXPKGS_ALLOW_UNFREE=1 && nix-build --arg buildInstaller false --arg buildBundle false --arg buildLive false --arg buildDisk true
error:
       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:9:12:
            8|
            9|   strict = derivationStrict drvAttrs;
             |            ^
           10|

       … while evaluating derivation 'playos-2024.7.0-VALIDATION'
         whose name attribute is located at /nix/store/27rg15w6bjjh2hkbdqajhvqd7b02v5cb-source/pkgs/stdenv/generic/make-derivation.nix:348:7

       … while evaluating attribute 'buildCommand' of derivation 'playos-2024.7.0-VALIDATION'
         at /home/yfyf/src/dividat/playos/default.nix:102:3:
          101|
          102|   buildCommand = ''
             |   ^
          103|     mkdir -p $out

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

       error: attribute 'config' missing
       at /nix/store/27rg15w6bjjh2hkbdqajhvqd7b02v5cb-source/lib/modules.nix:571:23:
          570|               #       options, so maybe that's why this is here.
          571|               isAttrs c.config || throw ''
             |                       ^
          572|                 In module `${c.file}', you're trying to define a value of type `${builtins.typeOf c.config}'

nix-build without any flags did also segfault earlier on my machine once.

[knuton]

My guess would be that the culprit is runInLinuxVM, for which there are similar sounding past issues:

• runInLinuxVM does not work on non-Linux NixOS/nixpkgs#73470
• runInLinuxVM fails if /dev/kvm is not world-read-writable like it is in NixOS NixOS/nixpkgs#124371

I removed the CI test commits from this PR; the issue is unrelated.

[knuton]

I think we could even consider removing this particular option: d871b01

I have not really used it much for testing, myself. I maybe wouldn't remove it just now, we can wait for a bit more insight from a non-NixOS dev environment.

Can you do ./build vm and then run the VM?

[yfyf]

Can you do ./build vm and then run the VM?

Yes, ./build vm and the built VM work totally fine!

[yfyf]

@knuton returning to the issue of the failing buildDisk case. I am trying to fix it, because I want to repurpose it as the first stage of system-level testing.

There is something weird going on here and seems to be dependent on the evaluation order. Maybe you can spot the issue here, because I spent way too long trying to debug it and failed to find the root cause. Here's what I have figured out so far:

My guess would be that the culprit is runInLinuxVM

Nope! This has nothing to do with runInLinuxVM, because nix fails before even starting any real "building".

In particular, the error cited above that I get when running ./build with only buildDisk=true is due to some nix module (c) not having a config attribute. --show-trace reveals that the evaluation path is roughly run-in-vm -> disk -> install-playos -> rescueSystem -> config.system.build.rescueSystem (see trace.txt for the full trace).

Now, the weird thing is that if I force disk to be built before run-in-vm (e.g. by adding ln -s ${components.disk} $out/disk.img as the second line of buildCommand), everything works. The question is... why?

My guess is that something "bad" happens due to bootloader/rescue being bizarrely recursive in how it defines its build output, though I might be wrong.

Anything else I could try to debug this further? Any way I could force nix to print the name of the mystery module c that is missing the config attribute? I know the "nix3" nix build has --debugger flag for that, but that is not available for the nix-build.

[yfyf]

Any way I could force nix to print the name of the mystery module c that is missing the config attribute?

I did a naughty thing and patched the source file in /nix/store to trace it, but the magic c is just the root package of nixos (/nix/store/27rg15w6bjjh2hkbdqajhvqd7b02v5cb-source/nixos/default.nix), which does not reveal much.

[knuton]

My guess is that something "bad" happens due to bootloader/rescue being bizarrely recursive in how it defines its build output, though I might be wrong.

I think this might be a red herring. The bizarre recursion is just part of NixOS's module system, unless I am missing a particular aspect you are pointing to. The invocation is evaluating the modules and returning an attribute set with the resolved config, which is going to include the system.build.rescueSystem output. I am not saying it's not bizarre, but I think it's just the regular mechanism.

[knuton]

I want to try to reproduce, you said you're running Debian?

[yfyf]

I think this might be a red herring.

You are probably right, I was just following the trace and noticed that rescueSystem is causing the error, rather than earlier inherit's, e.g. systemImage in this line and that systemImage avoids the self-reference to config, unlike rescueSystem.

I want to try to reproduce, you said you're running Debian?

Yes, Debian stable ("bookworm"), nix version 2.23 IIRC (I don't have access to the machine now, will let you know specifically later). It does not seem to be something distro-specific though, because as you observed earlier the same failures happen in the CI pipeline.

[knuton]

Yes, Debian stable ("bookworm"), nix version 2.23 IIRC (I don't have access to the machine now, will let you know specifically later).

Thanks. Multi-user or single-user (daemon or no daemon)?

[yfyf]

Thanks. Multi-user or single-user (daemon or no daemon)?

There ya go, full info:

[~]λ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.0-23-amd64, Debian GNU/Linux, 12 (bookworm), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.23.3`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

[yfyf]

@knuton so you were right, the buildDisk issue seems to be caused by some regression in nix. I can buildDisk with 2.8.0, 2.18.5 (stable) and 2.24.5 (latest), but 2.23.3 fails. I have rolled back to stable nix, which fixes the issue.

I guess it's not worth digging deeper, let's merge this PR and forget about it :)