… all load …
… 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.
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.
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:
Because they would be basically unconfigured and unusable. For now though, it does give you a working initial system from which you can
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.
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
So please make a call (everyone who feels entitled) and sanction the “blessed” route forward for my draft PR. I need tutorship.
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?
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?
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.
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.
I guess my PR is ready for final review, thank you all for your help!