installation CD (though the kernel on the CD is not recent
enough yet to actually support the device). (This is kind of
an abuse of "not-detected.nix".)
svn path=/nixos/trunk/; revision=30003
readme file as examples for an easy PXE setup.
This allows booting the NixOS in the system tarball, and thus allows installing nixos.
svn path=/nixos/trunk/; revision=28585
cause more problems than expected, so we should probably think about
the proper migration path for a while. In the meantime, of course,
everybody is encouraged to set boot.loader.grub.version = 2.
svn path=/nixos/trunk/; revision=27209
was never intended as a generic "check out anything" script; it's
just a convenience script to obtain the NixOS trunk after
installation. So that's what it should do.
svn path=/nixos/trunk/; revision=27005
cards because the default X config contains the Intel driver.
Likewise, there is no need for the "vesa" default.
* nixos-hardware-scan: Clean up the output a bit.
svn path=/nixos/trunk/; revision=26423
This is a followup to r23775 ("Substitute the path of the system
derivation directly in the stage 2 init script.").
svn path=/nixos/trunk/; revision=25582
hardware scan was generating a hardware.nix containing
"pkgs.linuxPackages" without having "pkgs" in scope. Also, it
shouldn't define boot.kernelPackages.
svn path=/nixos/trunk/; revision=25192
attribute name of the machine in the model. This allows
networking.hostName and deployment.targetHost to be omitted for
typical networks.
svn path=/nixos/trunk/; revision=25125
- implemented --no-out-link option so that invoking these tools from scripts leave no garbage behind
- some misc. cleanups
svn path=/nixos/trunk/; revision=25019
- Added a backdoor option to the interactive run-vms script. This allows me to intergrate the virtual network approach with Disnix
- Small documentation fixes
Some explanation:
The nixos-build-vms command line tool can be used to build a virtual network of a network.nix specification.
For example, a network configuration (network.nix) could look like this:
{
test1 =
{pkgs, config, ...}:
{
services.openssh.enable = true;
...
};
test2 =
{pkgs, config, ...}:
{
services.openssh.enable = true;
services.xserver.enable = true;
}
;
}
By typing the following instruction:
$ nixos-build-vms -n network.nix
a virtual network is built, which can be started by typing:
$ ./result/bin/run-vms
It is also possible to enable a backdoor. In this case *.socket files are stored in the current directory
which can be used by the end-user to invoke remote instruction on a VM in the network through a Unix
domain socket.
For example by building the network with the following instructions:
$ nixos-build-vms -n network.nix --use-backdoor
and launching the virtual network:
$ ./result/bin/run-vms
You can find two socket files in your current directory, namely: test1.socket and test2.socket.
These Unix domain sockets can be used to remotely administer the test1 and test2 machine
in the virtual network.
For example by running:
$ socat ./test1.socket stdio
ls /root
You can retrieve the contents of the /root directory of the virtual machine with identifier test1
svn path=/nixos/trunk/; revision=24410
{
test1 = {pkgs, config, ...}:
{
# NixOS config of machine test1
...
};
test2 = {pkgs, config, ...}:
{
# NixOS config of machine test2
...
};
}
And an infrastructure expression, e.g:
{
test1 = {
hostName = "test1.example.org";
system = "i686-linux";
};
test2 = {
hostName = "test2.example.org";
system = "x86_64-linux";
};
}
And by executing:
nixos-deploy-network -n network.nix -i infrastructure.nix
The system configurations in the network expression are built, transferred to the machines in the network and finally activated.
svn path=/nixos/trunk/; revision=24146
devices. These are used to replace hand made listings in the basic
installation CD.
The configuration file, which is generated by nixos-hardware-scan, enables
not-detected devices by default.
svn path=/nixos/trunk/; revision=23911
init script. This removes the need for the `systemConfig' boot
parameter; `init=<stage-2-init>' is enough. However, the GRUB menu
builder still needs to add `systemConfig' to the kernel command line
for compatibility with old configurations.
svn path=/nixos/trunk/; revision=23775
like `build-vm', but boots using the regular boot loader (i.e. GRUB
1 or 2) rather than booting directly from the kernel/initrd. Thus
it allows testing of GRUB.
svn path=/nixos/trunk/; revision=23747
root=... kernel command line parameter, instead of hard-coding it in
`fileSystems'. This is to allow CD-to-USB converters such as
UNetbootin to rewrite the kernel command line to the label or UUID
of the USB stick.
svn path=/nixos/trunk/; revision=23024
we want to generate the GRUB menu without actually installing GRUB
(because Amazon supplies its own pv-grub), and each menu entry
requires "root (hd0)". For the first, allow boot.loader.grub.device
to be set to "nodev" to indicate that the GRUB menu should be
generated without installing GRUB. For the second, add an option
boot.loader.grub.extraPerEntryConfig to allow commands to be added
to each GRUB menu entry (in this case, "root (hd0)").
svn path=/nixos/trunk/; revision=22712
grub.cfg before the menu entries. (This could also be done using
`extraEntriesBeforeNixOS', but then you can't have entries *after*
the main entry anymore.)
* In the installer test, redirect GRUB output to the serial port.
svn path=/nixos/branches/boot-order/; revision=22300
What I want with this derivation is to allow the sheevaplug nixos to
build a tarball with all the needed files to boot. Then, this can be
unpacked into an SD card, or into a NFS/TFTP server, and then the
user can boot the system with help of the uboot console.
By now, I have only tried to build the tarball in a PC, in order
to develop the nix expressions quicker.
There is nothing written specialy for the Sheevaplug in all this,
by now.
svn path=/nixos/trunk/; revision=20035
to the nixpkgs trunk 'kernelPackages'.
Seeing a strange kernelPackages mentioned in installation-cd-rescue (2.6.31_something) I
update that to 2.6.32.
svn path=/nixos/trunk/; revision=19443
is done by instantiating a webserver that simulates nixos.org.
Using nix-push we create a channel that contains some stuff (namely
the GNU Hello source tarball and the rlwrap program). This was a
bit tricky because nix-push requires a writable Nix store. Using
AUFS this is possible, but not on recent Linux kernels (AUFS1 over
CIFS fails).
svn path=/nixos/trunk/; revision=19327
installation-cd-minimal.nix is now 2.6.32. Added most of its extra
tools to installation-cd-base.nix.
* Put memtest86 at the bottom of the GRUB menu. (There is currently
no good way to do this other than to change the module inclusion
order.)
svn path=/nixos/trunk/; revision=19188
partition from /. If so, copy the kernels and initrds to /boot and
use paths relative to /boot in the GRUB configuration file. This
makes the boot.loader.grub.bootDevice option obsolete. (Is there a
way to mark obsolete options?) It also makes it unnecessary to set
boot.loader.grub.copyKernels, although that option is still
available since it can speed up GRUB if the Nix store is very
large.
svn path=/nixos/trunk/; revision=18998
GRUB version changes. (That's the complete version from the name
attribute, not the boot.loader.grub.version attribute.) The current
version is recorded in /boot/grub/version. This is required to
prevent massive breakage when we change the default value of
boot.loader.grub.version to "2".
svn path=/nixos/trunk/; revision=18997
expose makeInfo (used by test now)
expose config hack
* Adding tests to release.nix
* fixes
* removing dependency on perl
refactoring details:
Move all configuration modules used by the NixOS installation test script
into one directory.
svn path=/nixos/trunk/; revision=18982
is not on the same partition as /boot (i.e. when
boot.loader.grub.bootDevice is set): just copy the background image
and the font to /boot.
svn path=/nixos/trunk/; revision=18979
modules that should be added to the initrd, but should only be
loaded on demand (e.g. by the kernel or by udev). This is
especially useful in the installation CD, where we now only load the
modules needed by the hardware.
* Enable automatic modprobing by udev in the initrd.
svn path=/nixos/trunk/; revision=18975
You can run the kvm nixos installation test by:
nix-build --no-out-link tests/test-nixos-install-from-cd.nix
It boots the installed system.
It still fails sshd isn't started (yet)
adding nixos-bootstrapping-archive:
You can install NixOS easily using any live cd now.
See README-BOOTSTRAP-NIXOS
svn path=/nixos/trunk/; revision=18950
qemu_kvm. Installation doesn't take place yet. VM is started
printing a remote controlled "Hello".
This serves as example how to run a vm within a bulid job.
svn path=/nixos/trunk/; revision=18887
the /init and /system symlinks on the CD (since it removes the
cyclic dependency between building the Grub menu and the system
derivation).
svn path=/nixos/branches/upstart-0.6/; revision=18344
stdenv-updates stuff. Still to be reviewed, but at least an implementation to have
some different armv5tel-linux platforms: qemu versatile and the sheevaplug.
svn path=/nixos/trunk/; revision=18290
* Replace an obscure piece of code by its equivalent based on the
recursiveUpdate function. Undefined the obsolete name of
boot.grubDevice to avoid conflicts.
svn path=/nixos/trunk/; revision=18049
* Renamed some of the new Grub options to more sensible names
(e.g. extraGrubEntries to extraEntries, bootMount to bootDevice,
etc.).
svn path=/nixos/trunk/; revision=17494
grub. Its options are no more inside 'boot', but inside 'boot.loader.grub'.
I added a new bootloader configuration for nixos, generationsDir. It creates
/boot/default/{init,initrd,kernel,system} symlinks, and the same for the generations
in /boot/system-$gen/{init,initrd,kernel,system}.
I can program the u-boot loader to load /boot/default files always, and have
a minimal nixos boot loader installer functionality. Additionally, I can refer
to the other system generations easily, with a simple 'ls' in /boot.
svn path=/nixos/trunk/; revision=17460
* Change the module syntax of the example to follow Eelco's suggestions.
* Add a section "Building your own NixOS CD", which explain how to replace
configuration.nix by the configuration file of a live CD/DVD.
* Fix "Testing the installer" and "Testing the initrd" to fit the location
of derivations.
svn path=/nixos/trunk/; revision=17105
into one argument "modules".
* release.nix: fixed the manual job.
* ISO generation: break an infinite recursion. Don't know why this
suddenly happens. Probably because of the nixpkgs.config change,
but I don't see why. Maybe the option evaluation is too strict.
svn path=/nixos/trunk/; revision=16878
machine containing a replica (minus the state) of the system
configuration. This is mostly useful for testing configuration
changes prior to doing an actual "nixos-rebuild switch" (or even
"nixos-rebuild test"). The VM can be started as follows:
$ nixos-rebuild build-vm
$ ./result/bin/run-*-vm
which starts a KVM/QEMU instance. Additional QEMU options can be
passed through the QEMU_OPTS environment variable
(e.g. QEMU_OPTS="-redir tcp:8080::80" to forward a host port to the
guest). The fileSystem attribute of the regular system
configuration is ignored (using mkOverride), because obviously we
can't allow the VM to access the host's block devices. Instead, at
startup the VM creates an empty disk image in ./<hostname>.qcow2 to
store the VM's root filesystem.
Building a VM in this way is efficient because the VM shares its Nix
store with the host (through a CIFS mount). However, because the
Nix store of the host is mounted read-only in the guest, you cannot
run Nix build actions inside the VM. Therefore the VM can only be
reconfigured by re-running "nixos-rebuild build-vm" on the host and
restarting the VM.
svn path=/nixos/trunk/; revision=16662
