The wpa_supplicant service in the NixOS installer is unusable because
the control socket is disabled and /etc/wpa_supplicant.conf ignored.
The manual currently recommends manually starting the daemon and using
wpa_passphrase, but this requires figuring out the interface name,
driver and only works for WPA2 personal networks.
By enabling the control socket, instead, a user can configure the
network via wpa_cli (or wpa_gui in the graphical installer), which
support more advanced network configurations.
The essential commands from the NixOS installer as a package
With this package, you get the commands like nixos-generate-config and
nixos-install that you would otherwise only find on a NixOS system, such
as an installer image.
This way, you can install NixOS using a machine that only has Nix.
It also includes the manpages, which are important because the commands
rely on those for providing --help.
We're really setting users up on the wrong path if we tell them to
nix-env -iA immediately after installing. Instead, let's just
reassure them that installing software will be covered in due course
in the manual, to encourage them to keep reading.
Right now the UX for installing NixOS on a headless system is very bad.
To enable sshd without physical steps users have to have either physical
access or need to be very knowledge-able to figure out how to modify the
installation image by hand to put an `sshd.service` symlink in the
right directory in /nix/store. This is in particular a problem on ARM
SBCs (single board computer) but also other hardware where network is
the only meaningful way to access the hardware.
This commit enables sshd by default. This does not give anyone access to
the NixOS installer since by default. There is no user with a non-empty
password or key. It makes it easy however to add ssh keys to the
installation image (usb stick, sd-card on arm boards) by simply mounting
it and adding a keys to `/root/.ssh/authorized_keys`.
Importantly this should not require nix/nixos on the machine that
prepare the installation device and even feasiable on non-linux systems
by using ext4 third party drivers.
Potential new threats: Since this enables sshd by default a
potential bug in openssh could lead to remote code execution. Openssh
has a very good track-record over the last 20 years, which makes it
far more likely that Linux itself would have a remote code execution
vulnerability. It is trusted by millions of servers on many operating
systems to be exposed to the internet by default.
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
With 'set 3 boot on' the error 'file system "/boot" is not a FAT EFI
system partition (ESP) file system' occurs when running
"nixos-install" during the basic installation (tested in in a
VirtualBox VM).
Virtualbox recommends VMSVGA for Linux guests.
It is also currently the only one supporting 3D acceleration
and it works out of the box with NixOS and auto screen resizing.
Running the manual on a TTY is useless in the graphical ISOs and not
particularly useful in non-graphical ISOs (since you can also run
'nixos-help').
Fixes#83157.
There's many reason why it is and is going to
continue to be difficult to do this:
1. All display-managers (excluding slim) default PAM rules
disallow root auto login.
2. We can't use wayland
3. We have to use system-wide pulseaudio
4. It could break applications in the session.
This happened to dolphin in plasma5
in the past.
This is a growing technical debt, let's just use
passwordless sudo.
Compatibility with other distributions/software and expectation
of users coming from other systems should have higher priority over consistency.
In particular this fixes#51375, where the NetworkManager-wait-online.service
broke as a result of this.
The previous tentative to the fix got the order mixed up a bit. This
new fix has been re-verified to get them in the good order as per the
instructions in the following chapters.
The tests in <nixos/tests/installer.nix> are using `parted`, so they are
bound to be better tested than `fdisk`.
This is brought on by a couple issues, plus reports on IRC that the
`fdisk` instructions didn't work as expected.
* #39354
* #46309
* #39942
* #45478
Care was taken so that the other documented steps did not need changes.
In all this kerfufle, a slight re-organization of the Chapter has been
made, allowing better deep linking.
While it seemingly brings more attention to the macOS notes with the
default docbook template, it better represents which parts of the
section are about macOS, and which parts are simply in the flow of the
text; otherwise the last paragraph may be lost into the details for
macOS.
The instructions to install nixos behind a proxy were not clear. While
one could guess that setting http_proxy variables can get the install
rolling, one could end up with an installed system where the proxy
settings for the nix-daemon are not configured.
This commit updates the documentation with
1. steps to install behind a proxy
2. configure the global proxy settings so that nix-daemon can access
internet.
3. Pointers to use nesting.clone in case one has to use different proxy
settings on different networks.
* improve nix installation instructions
in the command
$ bash <(curl https://nixos.org/nix/install)
<(..) is a bashism. The documentation now show a command that does
not require to be executed by bash.
- mkfs.fat needs `-n` to set a partition label, not `-L`.
- create /mnt/boot before mounting
- leave out detailed LVM example as advanced users already how to create
LVs while it is detracting for novices.
Re #38674
New thin laptops don't have an ethernet port and so rely on wifi to get
access. With the minimal installer, setup wpa_supplicant can be hard if
it is the first time so here we provide an example.
"Ejecting" from the Finder ejects the entire device which is then not available for dd. diskutil unmountDisk does the right thing. Furthermore writing to diskN instead of rdiskN failed to complete even after waiting >10 minutes.
