toplevel build target missing

[tomfitzhenry]

Prior to the pinned-nixpkgs changes in August, I used build.toplevel to build the root filesystem, which I then copied to my Pinephone via nix-copy-closure.

Since the pinned-nixpkgs changes, this fails:

$ nix-build --argstr device pine64-pinephone -A build.toplevel
trace: ***************************************
trace: * Evaluating device: pine64-pinephone *
trace: ***************************************
trace: The `build` argument has been renamed `outputs`. This alias will be removed after 2022-05.
trace: 

********************************************
* WARNING: evaluation includes ./local.nix *
********************************************

trace: Building with crossSystem?: aarch64-linux != aarch64-linux → we're not.
error: attribute 'toplevel' in selection path 'build.toplevel' not found

Is there a replacement for outputs.toplevel? I tried to find a suitable attribute via tab-completion, but did not find any:

$ nix-build --argstr device pine64-pinephone -A build.
build.android               build.device-metadata       build.initrd                build.rootfs
build.boot-partition        build.disk-image            build.initrd-meta           build.stage-0
build.default               build.extraUtils            build.none                  build.u-boot
build.depthcharge           build.generatedFilesystems  build.recovery              build.uefi

rootfs produced an img, not a directory suitable for ssh-copy-closure.

[samueldr]

toplevel is the NixOS system config output, so config.build.toplevel should do the trick.

I guess this is one that we could alias in the Mobile NixOS specific outputs.

We couldn't continue relying on the untyped and unchecked config.build attribute from NixOS. Though since config is available at the root of the eval, it should be trivial to get back to any of its outputs.

[tomfitzhenry]

toplevel is the NixOS system config output, so config.build.toplevel should do the trick.

Ah yes, config.system.build.toplevel worked, thanks!

I guess this is one that we could alias in the Mobile NixOS specific outputs.

I think it's reasonable for folk to rely on the NixOS outputs (treating Mobile NixOS more as a library than a separate system). Embarrassingly, I still use local.nix but really ought to just follow https://mobile.nixos.org/getting-started.html#_using_in_your_system_configuration (which I had forgotten about).

[sergei-mironov]

Ah yes, config.system.build.toplevel worked, thanks!

Confirmed. As I can see, this builds me what looks like a profile generation. I am able to push it to the device (aslo a Pinephone) with nix-copy-closure, and then call

(pinephone) $ sudo /nix/store/...-nixos-system-nixos-21.11pre-git/bin/switch-to-configuration switch

But then I see

Warning: do not know how to make this configuration bootable; please enable a boot loader.
...
activating the configuration...
...

In the end the system switches the profile but only for the current boot. Could you please drop me a hint how to make changes permanent without re-flashing? I assume there should be a way to add an item to the recovery menu, but how?

[zhaofengli]

In the end the system switches the profile but only for the current boot. Could you please drop me a hint how to make changes permanent without re-flashing? I assume there should be a way to add an item to the recovery menu, but how?

You need to also nix-env --profile /nix/var/nix/profiles/system --set /nix/store/xxx-nixos-system

[samueldr]

Note that:

Warning: do not know how to make this configuration bootable; please enable a boot loader.

Is not related to the change not being permanent. This is a warning from the NixOS infra telling you it doesn't know how Mobile NixOS boots. This is not a problem, as Mobile NixOS detects generations when added to a profile like @zhaofengli shared.

[sergei-mironov]

nix-env --profile /nix/var/nix/profiles/system --set /nix/store/xxx-nixos-system

@samueldr @zhaofengli I confirm, this works, thanks! Adding new profile this way also updates the recovery menu.