Can NixOS be easier to install into baremetal?

[a9tm]

Issue description

Is there a WIP that helps to install NixOS on bare metal easier? NixOS installation is an hassle, comparing to fresh install Debian is way more simple.

Steps to reproduce

https://nixos.org/nixos/manual/index.html#sec-installation

Technical details

[Mic92]

Can you concretize what you are missing from installing nixos? We have infinite methods to install nixos.

[a9tm]

It's too manual and no installer. Am I asking too much?

[edolstra]

See #15573, #21662.

[Mic92]

https://nixos.org/nixops/ solves this partially for some providers.
We have also a terraform plugin that recently got added to nixpkgs: https://github.com/tweag/terraform-provider-nixos
Otherwise I don't see actionable items from issue.

[cx405]

Completely disagree with OP. Desktop user here, Nixos newbie, no Haskell experience, I have installed and used Gentoo, Arch(classic), many times installed Debian Stable. Nixos is a huge paradigm shift - some things are different, because the concepts are different and do not apply to it - not because there is no time to make a GUI installer.

With Debian people just add stuff over time - which is much quicker, much more convenient - but then stuff breaks and all hell goes loose. This applies to all classic binary distributions.
This is completely different with NixOS - because it "uses programming language as a configuration file" and only because of this it flexible and future proof. The price for this is a steep learning curve for user, because of total paradigm shift. After user understands its principles and can create plausible configuration.nix, everything is set and in the almost impossible case of rootfs becoming trashed (because rootfs in nixos is read-only), the new reinstallation comes down to mounting the FS, copying existing configuration.nix over and launching "nixos-install" with no fiddling past that. The Debian would kill many hours again in contrast.

TL;DR
NixOS is upfront configuration, where configuration is code and state is atomic; where in Debian configuration is direct edit (manual and automatic) of many text files with need for manual interventions during migration, during which system risks staying in half-broken state.

It's too manual and no installer. Am I asking too much?

Basically yes, please see yourself:
The installer is called nixos-install and it does everything what upfront configuration installer should do.
The "too manual" is inevitable, because its the very nature of Nix. Writing code is always manual, in nix - configuration is not just text, but code and there is a good reason for it to be so, as the payback is flexibility, future proof and saving of lots of headache at price of slower learning pace.

[7c6f434c]

@cx405 Strictly speaking, configuration.nix is checked against a strict schema. It is possible in principle to create a specialised UI for editing it, just as it is possible to create specialised UIs for editing HTML (or SmallTalk). It is also possible to create an optional UI for creating missing partitions (of course, once you roughly know what you are doing all the UIs for managing partitions become a lot more annoying than just using the underlying tools).

It's another story that different projects at different stages of development have different bottlenecks, and such an UI is probably not solving any of our current bottlenecks. It might still be too risky to use NixOS without knowing Nix (the system won't break on upgrade, but one might be stuck while trying to upgrade and it is way easier to guide users through complicated tricks when the users actually have looked at the three manuals); just a configuration editor will not solve the problem here.

[cx405]

@7c6f434c I want to contribute more to this issue, if you allow. The same kind of question, that OP asked has been actually going through my own head - why is it so complicated, why they don't use var=value; instead of dedicated nix language, but then I understood that this would essentially make Windows registry, with exact same issues like migration difficulties and replacing configuration with configuration. Thus hiding the mechanic behind yet another text config would contribute to new problem(s).

Plus, even if I would have a GUI application for something that is up-front configured and using the configuration language for configuration - I would not need to learn nix, which will lead to my inability to handle problems, write proper reports and manage the system to full potential. Do you think Nixos ecosystem would profit from users that can't write the reports, especially at current point?

I strongly think that we instead need to inform the new users about the "pros" and the resulting "cons", so that they expect the reason behind the current design.

This is why I for myself decided to jump right into the cold water, by installing nixos on bare hardware as my main machine and to actually live and document all the deficiencies that I have encountered so that I have motivation to understand and learn from them. This is also how I learned Gentoo in the past. The fastest way to learn is - jump into the cold water with a browser+text editor(+music application?**).

So the only thing I agreed upon was keeping the clean, sorted, "unbracketed" (steamlined) style inside configuration.nix, for example this is an extract:

{ config, pkgs, ... }:
let master = import <nixos-master> {}; in

{
imports = [ ./hardware-configuration.nix ];
system.stateVersion = "17.09";
  ##^ systemvar. change only if update process says so.
  ## THIS IS CORE PROFILE. DO NOT TOUCH EVEN AFTER UPDATE, OR ROLLBACK BREAKS.
nix.useSandbox = true;
  ##^ this basically causes complete clean of build environment
nix.buildCores = 0;
  ##^ 0 means "use all available"
nix.maxJobs = 4;
  ##^ matches amount of cpu cores, also used for parallel downloads
nixpkgs.config.allowUnfree = true; 
  ##^ enable to allow firmware and similar closed things in tree.
nixpkgs.config.allowBroken = false; 
  ##^ enable to allow broken packages, this is not recommended.
nixpkgs.config.firefox.enableAdobeFlash = true;
  ##^ must research into "nixpkgs.config" more!
nixpkgs.config.packageOverrides = pkgs: { 
xterm = pkgs.kdeApplications.konsole; 
};
  ##^ xterm entry tries to replace xterm package with konsole package.
nixpkgs.config.pulseaudio = true;
  ##^ enable systemwide pulse integration.

environment.systemPackages = with pkgs; [
##-- -- dependecies
cdrkit
ffmpeg-full
frei0r
libav
libav_12
  ##^ deps of pkg: kdenlive
mpv
  ##^ deps of pkg: smplayer
##-- -- console stuff
bash
bc
binutils
curl
f2fs-tools
file
fuse
gamin
gpm
gitAndTools.gitFull
hdparm
htop
libva-full
libav
libav_12
links2
##-- -- desktop-level services: services for xorg/wayland applications.
desktop_file_utils
glxinfo
gst_all_1.gnonlin
gst_all_1.gst-libav
gst_all_1.gst-plugins-bad
gst_all_1.gst-plugins-base
gst_all_1.gst-plugins-good
gst_all_1.gst-plugins-ugly
gst_all_1.gst-vaapi
gst_all_1.gstreamer
icedtea_web
kdeplasma-addons
##-- -- i18n, documentation and similar stuff
kdeFrameworks.ki18n
##-- -- desktop stuff, pure desktop applications.
ark
audacity
colord-kde
inkscape
firefox
gimp-with-plugins
gsmartcontrol
gwenview
kate
kcalc
kdeApplications.dolphin-plugins
kdeApplications.kdegraphics-thumbnailers
kdeApplications.kdenetwork-filesharing
kdeApplications.kdenlive
kdeApplications.kdf
kdeApplications.kgpg
kdeApplications.kwalletmanager
kdeApplications.okteta
kdeApplications.okular
kdeApplications.print-manager
kdeApplications.spectacle
keepassx-community
konversation
krita
krename
leafpad
libreoffice-fresh
obs-studio
partition-manager
smplayer
smtube
unetbootin
zim
##-- -- games and similar stuff
doomseeker
zandronum
##-- -- testing: testing stuff
transcode
# amarok-kf5
  ##^ broken
];
programs.bash.enableCompletion = true;
programs.gnupg.agent.enable = true;
programs.gnupg.agent.enableSSHSupport = true;

services.acpid.enable = true;
services.kmscon.hwRender = true;
services.locate.enable = true;
services.nixosManual.showManual = true;
## ....
}

but its my own preference. I can post full config, if someone is interested, this is from a working desktop baremetal system. Some call it awkward (and use lots of importing/fragmenting + bracketed notation), some like it, both is fine.

I am currently learning how I can make all the proprietary games run on my desktop system. For this, I again, need to learn nix a bit more, which I am happy to do. And should anything break - I have the config file, my notes and a live usb image for full reinstall within 10 minutes. I have already borked the system once and it was a great experience (the stateVersion var).

** initially the sound setup on my machine was borked, so I could play no music in the background. This is how I got my first report and was helped in managing a public fix.

[7c6f434c]

@cx405 well, who I am to even try to ask someone not to participate in a discussion.

I think a point can be made that a good and familiar editor is better than a poor editor for editing configuration.nix, and that a context-aware completion is a good thing (if only someone would implement it), and a lot of configurations sufficient for real use do not use anything beyond literal-value assignments. And then you cannot distinguish the actual use of a well-configured editor from a specialised configuration-editing UI that happens to allow direct Nix code entry for the rare cases when you need to actually enter a function (and some support for with).

And people have different learning curves.

I generally agree that if editing a configuration.nix file is actually a problem (I personally consider Nix-based «partition/mount/write expression/run a script» installation — be it precisely NixOS or not — easier to do than navigating one more installation UI), using NixOS will probably not be comfortable.

[alexeymuranov]

I would like to mention that recently i was looking for a Linux that i could install to and run from a USB flash drive in GPT mode, and after a failed experiment with Ubuntu, an unsatisfactory experience with Slax (in MBR mode), and after wasting some time trying to figure out how to do it with other distributions, i tried to run nixos-install from under NixOS onto my flash drive (after all the preliminary partitioning, formatting, mounting, and configuring), and it just worked.

Disclaimer: i can now run NixOS from a 8GB USB 2.0 flash drive on my laptop, but when i booted a desktop Mac form it, it somehow couldn't establish Ethernet connection, so there is still work to be done.

[wmertens]

I could imagine a very simple installer that asks some basics like keyboard layout and GUI, lets you pick/edit partitions and from then on you are on your own.

If someone were to make this in a way that would be maintainable long-term, that would certainly be nice.

I could also imagine an editor for configuration.nix that lets you edit the attribute set as long as it's like JSON, and any complexity would have to be implemented by modules somewhere else.

But the most benefit for current and future users would come from a project that manages add-in modules that provide configurations configured with simple values. Exactly like NixOS modules, but outside of the tree, using overlays.

There could be hardware overlays that configure the drivers and services needed to make specific laptops worb, for example. Overlays that are good and generic enough could end up in nixpkgs.

So a tool that manages a registry of overlays, an editor for configuration.nix (with options expanding etc) and finally an installer that uses those to provide a macOS-like install.

[andrewchambers]

The biggest issue is most "normal" people don't know how to parition and setup mounts.

fdisk, gdisk or sgdisk are all difficult to use, nixos-install is easy to use.

The openbsd installer is a good example of a spartan installer that can suggest automatic disk partitions for you.

[alexeymuranov]

The biggest issue is most "normal" people don't know how to parition and setup mounts.

A solution for "normal" people could be to read installation instructions for NixOS. As to partitioning, there exist graphical partitioning tools, there is no need IMO for the installer to take care of this. (Personally, i keep falling back to gdisk as the most reliable and predictable tool for me.)

It is possible though that the installation instructions could be simplified or clarified further, with precise recipes for some common cases (maybe adding a screencast?).

For me, installing NixOS is the easy part, but configuring it afterwords is tricky. I am still using it mostly for experiments because i cannot get rid of some glitches. So, i see little point in making a graphical installer that allows to easily select some basic options without editing configuration.nix because afterwards the user will need to edit it anyway.

[andrewchambers]

The installation instructions are not bad, I just think you will continue to get complaints because the tools provided and the goal are not aligned.

The tools suggested: fdisk, gdisk are fundamentally about patitioning drives, however this is not the users goal, the end users real goal is to have a sensible install of nixos with little hassle. Most people don't want to learn about magic disk numbers/EFI/MBR. They just want it to boot. Manually typing stuff they don't care about is just a pain.

Btw, I think it is totally valid for Nixos to not care about less technical users. Having a difficult install could actually be a filter for higher quality contributors as crazy as that sounds.

[alexeymuranov]

The tools suggested: fdisk, gdisk are fundamentally about patitioning drives, however this is not the users goal, the end users real goal is to have a sensible install of nixos with little hassle.

Well, but looking again into the current instructions, they seem to suggest a sensible install with 512MB ESP, 8GB swap, and a single Ext4 partition for the rest. If following these instructions is a hassle, while they are to be executed only once for a given hard drive, i am not sure if the person really wants NixOS :).

However, these instructions seem indeed a bit complicated and scary at the first look, in particular because they combine together such independent issues as partitioning, formatting, creating LVM volumes, dealing with possible network issues, installing by ssh, etc. IMO it would have helped to separate the issues and to provide a basic "quick-start" 10-line solution for a "sensible" installation. A screencast could help too.

The official instructions being somewhat overwhelming for me, i keep referring to my own write-up.

On the other hand, i would have really appreciated an official example of a "sensible" configuration.nix. I keep modifying mine by trial and error and by borrowing what i find online in other people's configuration.nix.

[oxij]

A dollar and two cents from related SLNOS documentation FYI in case someone is willing to steal something from it. * Installer ** Diffs *** NixOS **** Structural - SLNOS has boot management (bootable vs. descriptive system separation), NixOS does not. **** Assumptions - We assume most users have some NixOS/SLNOS infrastructure already and want to use it instead of doing everything from scratch. For instance, a user has a bunch of NixOS/SLNOS machines and has an almost-working NixOS configuration he wants to adapt to the target. - We assume some users want to keep configuration sources private from the target. Hence we require no .nix files on the target's root. - We try to make installer less impure over nix and system utilities because we assume SLNOS will eventually patch all of them and we want to bootstrap easily. - NixOS installer assumes low-memory and tries to minimize memory usage by default. We try to minimize build+install time under our assumptions by default. In particular, we don't target systems that can't nix-instantiate their own configuration right after live system boots (this can be done with some hackery, though). If you're installing on a low-end router you should add some swap. **** Notable features - We have semi-automated partitioning derived from system configuration. - We support cross-build cross-install. - We have cruise control. *** GuixSD **** Structural - SLNOS is mostly NixOS, GuixSD is not. **** Assumptions - We are not trying to be "user-friendly" in the conventional sense. - Infrastructure assumptions above. ** Algorithm - Users boot current-system from CD/USB/Netboot. - Ask for locale, TZ, keyboard layout, console font. - Start getty, tty manual. - Remind users to attach swap. - Drop to login shell. Note: this gives a usable rescue system. - Users clone/mount configuration/nixpkgs git/rsync/etc sources, ssh keys, binary caches, other stores, etc. - Users run `slnos-install`. - slnos-install (sh -e) : target-system.nix : .nix-file that builds to bootable store-path -> build-closure : installer store-path URI =(def) current-system.installer -> partitioning-script : nullOr path : Toposorted, idempotent, script that does setup for any missing stuff, fails with an error if the current set of partitions is not a superset of what configuration wants. Has no deps, refs everything by name, not by store-path. -> etc : nullOr path =(def) null -> IO () - If $0 != build-closure/slnos-install: - nix-copy build-closure into the local /nix/store. - Reexec into never `slnos-install`. - Set PATH = build-closure/bin. - nix-instantiate target-system.nix into target-system.drv. - Realise derived partitioning-script. - Realise /etc/nix, /etc/fstab, and other such files. - Create and populate a derived-/etc with said files and stuff from the installer itself (e.g. hosts, resolv.conf). - If partitioning-script == null: - Set etc = derived partitioning-script. - Else: - Show diff. - Similarly for etc. - Remind users to save (commit/rsync/etc) their changes. - Give users a chance to abort (e.g. to edit files or to commit changes). - Run partitioning-script. - Mount target root. - Mount stuff from fstab and --rbind all the things. - mount --rbind etc /etc. - rsync build-closure/closure to root, register validity. - TODO Investigate: we can umount installer's /nix/store tmpfs overlay now to free some memory for the build. - Chroot. - nix-instantiate target-system.nix into target-system.drv. (Yes, again. nix.conf has changed.) - ready-system = realise target-system.drv. - umount /etc. - Print a "best effort" warning if not the same arch as ready-system. - Run `ready-system/activate-host` (or `activate-cross`) script. - Register ready-system in profiles. - Run `update-bootloader`, warn (not fail) on errors. - Drop to chroot shell. - Users do the finishing touches, if any, fix bootloaders, if broken. - Cleanup.

[avnik]

For my two cents -- thing which I'd like to see in installer -- is ability to give single link to downloaded metafile with desired channel (or git snapshot), local cache, and other stuff (for example -- I don't use channels, but I use local http cache and local git repos for modified nixpkgs and configs)

[NilsIrl]

on bare metal easier

NixOS has passed the stage where it is only run in QEMU a long time ago. It is even used in production.

This issue should probably be closed as it is just a duplicate of:

See #15573, #21662.

[7c6f434c]

@NilsIrl To be fair,

It is even used in production.

is not an argument in any direction here, because the issue is about lowering the necessary level of qualification for installing, and hopefully people running production servers with NixOS are way further along the learning curve.

Closing as duplicate might be a reasonable idea, of course.

[davidak]

OK, closing as duplicate of #21662.