Note that for attribute-based nix-env installations, the NixOS
channel contains Nixpkgs as its "pkgs" attribute, so
$ nix-env -iA nixos.pkgs.foo
will work instead of the old
$ nix-env -iA nixpkgs_sys.foo
* Fix the path to root's channels installed in ~/.nix-defexpr.
svn path=/nixos/trunk/; revision=33823
* Change the name of the top-level derivation from "system" to
"nixos-<version>".
* Show the NixOS version in the GRUB boot menu instead of the kernel
version.
svn path=/nixos/trunk/; revision=33785
I set the grub entry for memtest to read "Memtest86", as suggested by Eelco.
I run:
svn merge -c -33692 ^/nixos/trunk
And edited the change a bit.
svn path=/nixos/trunk/; revision=33734
currently activated NixOS. This is "0.1pre-svn" when built from a
SVN tree, but contains the actual revision when installed from the
NixOS channel or from the ISO.
svn path=/nixos/trunk/; revision=33730
rather than root. Also copy all manifests into the chroot so that
any nix-pull done outside the chroot is "inherited".
svn path=/nixos/trunk/; revision=33725
dhcpcd to segfault randomly or give corrupt output. See e.g.
http://hydra.nixos.org/build/2380666/nixlog/1/raw
The problem seems to be that wicd sends a "-k" command to dhcpcd to
release the interface, which doesn't work well with a dhcpcd that
handles all interfaces in one process.
svn path=/nixos/trunk/; revision=33720
the same as the usual nixos. I think this trivial change works;
I checked the grub.cfg output generated in the iso_minimal.
svn path=/nixos/trunk/; revision=33692
because it can be overriden choosing another memtest86.
As an effect of a change in nixpgks, the isos will include
memtest86 4.0a instead of memtest86+ 4.20, only because the
former is released later, and I deduce it should work better.
svn path=/nixos/trunk/; revision=33691
* Load scsi_wait_scan after all other kernel modules to ensure that
all SCSI device nodes have been created.
* Increase the timeout for the appearance of the root device to 20
seconds.
* Do a "udevadm settle" just after the root device has appeared to
make sure that udev isn't accessing the device anymore (hopefully).
On EC2 (Xen), I've seen fsck on the root fail randomly with "device
in use" errors.
svn path=/nixos/trunk/; revision=33650
challenge-response is an authentication method that does not need the
plain text password to be emitted over the (encrypted) connection.
This is nice if you don't fully trust the server.
It is enabled (upstream) by default.
To the end user, it still looks like normal password authentication,
but instead of sending it, it is used to hash some challenge.
This means that if you don't want passwords to be used ever at all,
and just stick to public key authentication, you probably want to
disable this option too.
svn path=/nixos/trunk/; revision=33513
