SD images: are they really installation devices?

blaggacao · January 26, 2021, 1:12am

… all load …

NixOS/nixpkgs/blob/68953d0486ab5f536c9145b5355cbcaa7e3047dc/nixos/modules/profiles/installation-device.nix

# Provide a basic configuration for installation devices like CDs.
{ config, pkgs, lib, ... }:

with lib;

{
  imports =
    [ # Enable devices which are usually scanned, because we don't know the
      # target system.
      ../installer/scan/detected.nix
      ../installer/scan/not-detected.nix

      # Allow "nixos-rebuild" to work properly by providing
      # /etc/nixos/configuration.nix.
      ./clone-config.nix

      # Include a copy of Nixpkgs so that nixos-install works out of
      # the box.
      ../installer/cd-dvd/channel.nix
    ];

This file has been truncated. show original

… where things like …

{
documentation.enable = mkForce true;  # space!
documentation.nixos.enable = mkForce true; # space!
networking.wireless.enable = mkDefault true; # confilcts with networking.networkmanager.eneable = true; - see error:
# Failed assertions:
# - You can not use networking.networkmanager with networking.wireless.
# Except if you mark some interfaces as <literal>unmanaged</literal> by NetworkManager.

}

… really seem undesired.

eadwu · January 26, 2021, 3:06am

This isn’t the mean use case. To even cross compile would require knowledge of the Nix command line in which case you wouldn’t have this problem and would just disable those options yourself.

dramforever · January 26, 2021, 1:29pm

I would argue that this is in fact the intended use case of the sdImage mechanism in NixOS. Otherwise it would make little sense that these images are built on Hydra:

https://hydra.nixos.org/job/nixos/trunk-combined/nixos.sd_image_raspberrypi4.aarch64-linux

Because they would be basically unconfigured and unusable. For now though, it does give you a working initial system from which you can nixos-rebuild.

Whether in general an SD image of a system is used this way, and whether sdImage as in NixOS does it’s job is another question.

If your claimed ‘mean use case’ is to be implemented, I don’t think it should override sdImage just because it has the unfortunate name that seems to implement a different use case that some users consider more common. If this were to be implemented it should be provided as a different option.

blaggacao · January 26, 2021, 1:40pm

I’m specifically eying at how netboot is implemented. I could easily use .../netboot.nix without the bells and whistles.

For the current sd images, that escape hatch is not even possible, unless I override which becomes a funny undertaking by measure of the use of lib.mkForce in installation-device.nix.

So please make a call (everyone who feels entitled) and sanction the “blessed” route forward for my draft PR. I need tutorship.

raboof · January 26, 2021, 4:21pm

You are pointing to derivations in the /nixos/modules/installer/ branch of the tree.

In that context, ‘installation device’ seems to make sense? Also I think it’s a valid use case: download a general-purpose NixOS SD image, flash it, pop it into your Raspberry PI and use it interactively.

Now, of course generating bespoke immutable SD images is also a great use case of Nix. Perhaps a better starting point than the installer images would be nixos-generators, though?

blaggacao · January 26, 2021, 4:51pm

That is an interesting idea, indeed!

My specific pain point is that I want to propose a specific functionality upstream into nrdxp/nixflk (for reasons of the benefits of the commons). Some of the abstractions developed at nrdxp/nixflk might eventually — so I hope — find their way into the even higher level abstractions of numtide/flake-utils (also for the benefit of the commons) — I’m actually already preemptively stumbling around on the latter.

I think it’s reasonable to assume that neither of those upstreams would be very keen on light-hartedly establish dependency on (yet) another repository.

Therefore, so my reasoning goes, getting this fixed upstream does effectively lower adoption barriers all the way down stream. And that seems to be a prerequisite in good faith for my plan.

On the other hand nixos-generators are pretty featureful so maybe they’ve got a chance at entering that upstream inclusion scrutiny, that I refer to.

UPDATE: looking at this, that repository looks like a competing as well as complementary source of truth, but at any rate, with definite overlap. Hm … Why has everything to be so complicated?

UPDATE2:
https://github.com/nix-community/nixos-generators/issues/85

I think I’ll be probably told: feel free to go ahead and fix the world … I’d hold up: would I be able to on my own? And if so, which I’m not confident of, spanning over how many project hops (that each reflect individual as well as shared, but different, realitites)?

I think this is a case of semantic shift over time. For example /nixos/modules/installer/netboot/ is not likely to behave as an installer, as this would be a bit opposite to the ideas of what netboot is.

blaggacao · January 28, 2021, 3:06am

I updated the PR and split the installer device from the bespoke base (similar as netboot is done multilevel). However I hope somebody can help me get this PR backwards compatible and help me find what (many) references need updating.

https://github.com/NixOS/nixpkgs/pull/110827

blaggacao · February 2, 2021, 10:45pm

I guess my PR is ready for final review, thank you all for your help!