Because when I see "config.system.build.manual.manual" after I forgot
what it means I ask "Why do I need that second `.manual` there again?".
Doesn't happen with `config.system.build.manual.manualHTML`.
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.
This is a 277K (as of right now) addition that can greatly help in some
last recourse scenarios. The specific rEFInd setup will not be able to
boot the installer image, but this is not why it has been added. It has
been added to make use of its volumes scanning capabilities to boot
existing EFI images on the target computer, which is sometimes necessary
with buggy EFI. While is isn't NixOS's job to fix buggy EFI, shipping
this small bit with the installer will help the unlucky few.
Example scenario: two wildly different EFI implementation I have
encountered have fatal flaws in which they sometimes will lose all the
settings, this includes boot configuration. This is compounded by the
fact that the two specific and distinct implementation do not allow
manually adding ESP paths from their interface. The only recourse is to
let the EFI boot the default paths, EFI/boot/boot{platform}.efi, which
is not a default location used by the NixOS bootloaders. rEFInd is able
to scan the volumes and detect the existing efi bootloaders, and boot
them successfully.
Following up https://github.com/NixOS/nixpkgs/pull/23665
Bootable USB-drives are not limited to ISO-images, there can be "normal" MBR/GPT-partitioned disk connected via USB-rack.
Also, "uas" implies "usb-storage", so there is no need to mention both.
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
When running e.g. `nixos-option boot.kernelPackages` I get an output
like this on the current unstable channel (18.09pre144959.be1461fc0ab):
```
$ nixos-option boot.kernelPackages
Value:
*exit 1*
```
This is fairly counter-intuitive as I have no clue what might went
wrong. `strace` delivers an output like this:
```
read(3, "error: Package \342\200\230cryptodev-linu"..., 128) = 128
read(3, "ux/cryptodev/default.nix:22 is m"..., 128) = 128
read(3, "lowBroken = true; }\nin configura"..., 128) = 128
read(3, "you can add\n { allowBroken = tr"..., 128) = 128
read(3, "n)\n", 128) = 3
read(3, "", 128) = 0
```
`nixos-option` evaluates the system config using `nix-instantiate` which
might break when the evaluation fails (e.g. due to broken or unfree
packages that are prohibited to evaluate by default). The script aborts
due to the shebang `@shell@ -e`.
In order to ensure that no unexpected
behavior occurs due to removing `-e` from the interpreter the easiest
way to work around this was to wrap `nix-instantiate` in `evalNix()`
with a `set +e`. The function checks the success of the evaluation with
`$?` in the end. Additionally `evalNix` shouldn't break, if one
evaluation (e.g. the values that contain a package set by default) to
return additional information like a description.
With the change `nixos-option boot.kernelPackages` delivers the
following output for me:
```
Value:
error: Package ‘cryptodev-linux-1.9-4.14.52’ in /nix/store/47z2s8cwppymmgzw6n7pbcashikyk5jk-nixos/nixos/pkgs/os-specific/linux/cryptodev/default.nix:22 is marked as broken, refusing to evaluate.
Default:
{ __unfix__ = <LAMBDA>; acpi_call = <CODE>; amdgpu-pro = <CODE>; ati_drivers_x11 = <CODE>; batman_adv = <CODE>; bbswitch = <CODE>; bcc = <CODE>; beegfs-module = <CODE>; blcr = <CODE>; broadcom_sta = <CODE>; callPackage = <CODE>; cpupower = <CODE>; cryptodev = <CODE>; dpdk = <CODE>; e1000e = <CODE>; ena = <CODE>; evdi = <CODE>; exfat-nofuse = <CODE>; extend = <CODE>; facetimehd = <CODE>; fusionio-vsl = <CODE>; hyperv-daemons = <CODE>; ixgbevf = <CODE>; jool = <CODE>; kernel = <CODE>; lttng-modules = <CODE>; mba6x_bl = <CODE>; mwprocapture = <CODE>; mxu11x0 = <CODE>; ndiswrapper = <CODE>; netatop = <CODE>; nvidiaPackages = <CODE>; nvidia_x11 = <CODE>; nvidia_x11_beta = <CODE>; nvidia_x11_legacy304 = <CODE>; nvidia_x11_legacy340 = <CODE>; nvidiabl = <CODE>; odp-dpdk = <CODE>; openafs = <CODE>; openafs_1_8 = <CODE>; perf = <CODE>; phc-intel = <CODE>; pktgen = <CODE>; ply = <CODE>; prl-tools = <CODE>; recurseForDerivations = true; rtl8192eu = <CODE>; rtl8723bs = <CODE>; rtl8812au = <CODE>; rtl8814au = <CODE>; rtlwifi_new = <CODE>; sch_cake = <CODE>; spl = <CODE>; splLegacyCrypto = <CODE>; splStable = <CODE>; splUnstable = <CODE>; stdenv = <CODE>; sysdig = <CODE>; systemtap = <CODE>; tbs = <CODE>; tmon = <CODE>; tp_smapi = <CODE>; usbip = <CODE>; v4l2loopback = <CODE>; v86d = <CODE>; vhba = <CODE>; virtualbox = <CODE>; virtualboxGuestAdditions = <CODE>; wireguard = <CODE>; x86_energy_perf_policy = <CODE>; zfs = <CODE>; zfsLegacyCrypto = <CODE>; zfsStable = <CODE>; zfsUnstable = <CODE>; }
Example:
{ _type = "literalExample"; text = "pkgs.linuxPackages_2_6_25"; }
Description:
"This option allows you to override the Linux kernel used by\nNixOS. Since things like external kernel module packages are\ntied to the kernel you're using, it also overrides those.\nThis option is a function that takes Nixpkgs as an argument\n(as a convenience), and returns an attribute set containing at\nthe very least an attribute <varname>kernel</varname>.\nAdditional attributes may be needed depending on your\nconfiguration. For instance, if you use the NVIDIA X driver,\nthen it also needs to contain an attribute\n<varname>nvidia_x11</varname>.\n"
Declared by:
"/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/kernel.nix"
Defined by:
"/home/ma27/Projects/nixos-config/system/boot.nix"
```
This partially reverts a change from e88f28965a
which removed the `mount --rbind /sys`.
While true that the activation scripts will mount `sysfs` at `/sys`,
none of the mountpoints lower in the `/sys` tree are handled by the
activation script, which includes `efivarfs`.
This fixes#38477 since it ensures the presence of `efivarfs` in the
`/sys` tree, which is why the systemd-boot installation failed.
Nothing probably uses this, but let's be pedantic and have the
pre-included channel on the install media be as close as possible to
what 'nix-channel --update' will give them.
The only remaining difference is that the channel adds programs.sqlite,
which is fundamentally unfixable.
Because it improves out-of-the-box user experience a lot (IMHO).
(zsh completion is already on by default.)
Remove "programs.bash.enableCompletion = true" from
nixos-generate-config.pl, which feels superflous now.
- Add `imageName` and `imageBaseName` options similar to the `isoName`
and `isoBaseName` options
- Make the filename of the iso match what iso-image.nix does
- Generate a nix-support/hydra-build-products like iso-image.nix does
The function arguments for make-squashfs.nix have changed in
df117acab7, so we need to change them here
as well.
The boot.netboot NixOS VM test now succeeds again.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
Of course, you'll get a bunch of warnings from the activation script:
$ nixos-enter --root /tmp/mnt/
setting up /etc...
mount: /dev: permission denied.
mount: /dev/pts: permission denied.
mount: /dev/shm: permission denied.
mount: /sys: permission denied.
/nix/var/nix/profiles/system/activate: line 74: /proc/sys/kernel/modprobe: Permission denied
chown: changing ownership of '/run/wrappers/wrappers.0pKlU8JsvV/dbus-daemon-launch-helper': Invalid argument
NOTE: Under Linux, effective file capabilities must either be empty, or
exactly match the union of selected permitted and inheritable bits.
Failed to set capabilities on file `/run/wrappers/wrappers.0pKlU8JsvV/ping' (Operation not permitted)
chown: changing ownership of '/run/wrappers/wrappers.0pKlU8JsvV/unix_chkpwd': Invalid argument
[root@nixos:/]#
The use of Nix 2.0 significantly simplifies the installer, since we
can just pass a different store URI (--store /mnt) - it's no longer
needed to set up a chroot environment for the build, and to bootstrap
Nix into the chroot.
Also, commands that need to run in the installation (namely boot
loader installation and setting a root password) are now executed
using nixos-enter.
This also removes the need for nixos-prepare-root since any required
initialisation is done by Nix or by the activation script.
In particular, it conflicts with `services.tlp.enable` option.
There exists workaround:
```
powerManagement.cpuFreqGovernor = lib.mkForce null;
services.tlp.enable = true;
```
But should it?
Regression introduced by 801c920e95.
Since then, the btrfsSimple subtest of the installer VM test fails with:
Btrfs did not return a path for the subvolume at /
The reason for this is that the output for "btrfs subvol show" has
changed between version 4.8.2 and 4.13.1.
For example the output of "btrfs subvol show /" in version 4.8.2 was:
/ is toplevel subvolume
In version 4.13.1, the output now is the following and thus the regular
expressions used in nixos-generate-config.pl and install-grub.pl now
match (which results in the error mentioned above):
/
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 287270
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
In order to fix this I've changed nixos-generate-config.pl and
install-grub.pl, because both use "btrfs subvol show" in a similar vein,
so the regex for parsing the output now doesn't match anymore whenever
the volume path is "/", which should result in the same behaviour as we
had with btrfs-progs version 4.8.2.
Tested against the btrfsSimple, btrfsSubvols and btrfsSubvolDefault
subtests of the installer VM test and they all succeed now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
