Upstart won't find a "bash" binary in $PATH when those commands are run, so we
refer to it using an absolute path.
svn path=/nixos/trunk/; revision=31157
pierron recommended the use of types.string over mergeOptionString, as
it is superior but might break things.
For my system the change evaluated to the exactly same.
svn path=/nixos/trunk/; revision=31138
This reverts commit 025f8c40b40fad50086e8761eee61098d8fb2651.
The check was intened for building the initrd of the installer.
svn path=/nixos/trunk/; revision=31137
popt-0.16 and cryptsetup-1.4.1 both generated pkgconfig (in contrast
to older versions). The pkgconfig files (popt.pc and cryptsetup.pc)
contain references into the store that are not removed by patchelf and
stage-1 fails with errors like: "output is not allowed to refer to
path `/nix/store/qccjhn063cfv171rcaxvxh0yk96zf7l2-cryptsetup-1.4.1'".
Now, only the cryptsetup binaries and its dependencies are copied,
determined by ldd. In addition the cryptsetup binary and lvm are
tested after patchelf has adjusted the library paths.
Thanks to Peter Simons and Eelco Dolstra for giving the rights hints.
svn path=/nixos/trunk/; revision=31128
After the change from revision 30103, nixos-rebuild suddenly consumed
freaky amounts of memory. I had to abort the process after it had
allocated well in excess of 30GB(!) of RAM. I'm not sure what is causing
this behavior, but undoing that assignment fixes the problem. The other
two commits needed to be revoked, too, because they depend on 30103.
svn path=/nixos/trunk/; revision=30127
possibility that a udevd process survives, preventing udevd from
starting in stage 2:
machine# udevd[1421]: bind failed: Address already in use
machine# udevd[1421]: error binding udev control socket
svn path=/nixos/trunk/; revision=29434
directory. This happened with /etc/polkit-1, which used to be a
symlink to /etc/static/polkit-1, which was itself a symlink but now
is a directory. Not handling this correctly led to /etc/static
being clobbered with symlinks pointing to themselves.
svn path=/nixos/trunk/; revision=29061
was already the case on Linux 2.6.32, but in newer kernels the CFQ
scheduler is built as a module, so all block devices got the ‘none’
scheduler instead.
svn path=/nixos/trunk/; revision=28972
then every unshare(CLONE_NEWNS) system call causes a new entry to be
created in /dev/cgroup/<pid>, which is not removed automatically.
This can cause subsequent calls to unshare() to fail if the PID has
wrapped around. Worse, a large number of entries in /dev/cgroup
causes a very substantial system slowdown: doing 10,000
fork()/unshare(CLONE_NEWNS)/exit() calls took 21s without the "ns"
subsystem, but 2m43s with it, and the system slows down permanently
until the entries in /dev/cgroup are removed (going to a load of > 6
on my laptop).
This is particularly important for Nix because its chroot feature
uses unshare(CLONE_NEWNS). (http://yellowgrass.org/issue/Nix/219)
svn path=/nixos/trunk/; revision=27216
