search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.09k stars 14.14k forks source link

Can NixOS be easier to install into baremetal? #38499

Closed a9tm closed 4 years ago

a9tm commented 6 years ago

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 commented 6 years ago

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

a9tm commented 6 years ago

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

edolstra commented 6 years ago

See #15573, #21662.

Mic92 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

A dollar and two cents from related SLNOS documentation FYI in case someone is willing to steal something from it.

**** Assumptions

**** Notable features

* GuixSD ** Structural

**** Assumptions

** Algorithm

Note: this gives a usable rescue system.

avnik commented 6 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

OK, closing as duplicate of https://github.com/NixOS/nixpkgs/issues/21662.