mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-10-31 06:31:20 +00:00
doc: Use prompt more often
This commit is contained in:
Jan Tojnar
parent
3c14bda7f5
commit
a3f2131eb6
@ -921,7 +921,7 @@ src = fetchFromGitHub {
|
||||
<para>
|
||||
You can convert between formats with nix-hash, for example:
|
||||
<screen>
|
||||
$ nix-hash --type sha256 --to-base32 <replaceable>HASH</replaceable>
|
||||
<prompt>$ </prompt>nix-hash --type sha256 --to-base32 <replaceable>HASH</replaceable>
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1038,7 +1038,7 @@ patches = [ ./0001-changes.patch ];
|
||||
<para>
|
||||
Move to the root directory of the source code you're patching.
|
||||
<screen>
|
||||
$ cd the/program/source</screen>
|
||||
<prompt>$ </prompt>cd the/program/source</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -1046,8 +1046,8 @@ $ cd the/program/source</screen>
|
||||
If a git repository is not already present, create one and stage all of
|
||||
the source files.
|
||||
<screen>
|
||||
$ git init
|
||||
$ git add .</screen>
|
||||
<prompt>$ </prompt>git init
|
||||
<prompt>$ </prompt>git add .</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -1060,7 +1060,7 @@ $ git add .</screen>
|
||||
<para>
|
||||
Use git to create a diff, and pipe the output to a patch file:
|
||||
<screen>
|
||||
$ git diff > nixpkgs/pkgs/the/package/0001-changes.patch</screen>
|
||||
<prompt>$ </prompt>git diff > nixpkgs/pkgs/the/package/0001-changes.patch</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
@ -480,9 +480,9 @@ pullImage {
|
||||
<literal>nix-prefetch-docker</literal> command can be used to get required
|
||||
image parameters:
|
||||
|
||||
<programlisting>
|
||||
$ nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5
|
||||
</screen>
|
||||
|
||||
Since a given <varname>imageName</varname> may transparently refer to a
|
||||
manifest list of images which support multiple architectures and/or
|
||||
@ -491,17 +491,17 @@ $ nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql
|
||||
By default it will match the OS and architecture of the host the command is
|
||||
run on.
|
||||
|
||||
<programlisting>
|
||||
$ nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux
|
||||
</screen>
|
||||
|
||||
Desired image name and tag can be set using
|
||||
<option>--final-image-name</option> and <option>--final-image-tag</option>
|
||||
arguments:
|
||||
|
||||
<programlisting>
|
||||
$ nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
||||
@ -131,8 +131,8 @@
|
||||
in <literal>beamPackages</literal>, use the following command:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ nix-env -f "<nixpkgs>" -qaP -A beamPackages
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -f "<nixpkgs>" -qaP -A beamPackages
|
||||
beamPackages.esqlite esqlite-0.2.1
|
||||
beamPackages.goldrush goldrush-0.1.7
|
||||
beamPackages.ibrowse ibrowse-4.2.2
|
||||
@ -140,16 +140,16 @@ beamPackages.jiffy jiffy-0.14.5
|
||||
beamPackages.lager lager-3.0.2
|
||||
beamPackages.meck meck-0.8.3
|
||||
beamPackages.rebar3-pc pc-1.1.0
|
||||
</programlisting>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
To install any of those packages into your profile, refer to them by their
|
||||
attribute path (first column):
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ nix-env -f "<nixpkgs>" -iA beamPackages.ibrowse
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix-env -f "<nixpkgs>" -iA beamPackages.ibrowse
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
The attribute path of any BEAM package corresponds to the name of that
|
||||
|
||||
@ -47,13 +47,13 @@ foo = import ../path/to/foo.nix {
|
||||
in <filename>all-packages.nix</filename>. You can test building a Perl
|
||||
package as follows:
|
||||
<screen>
|
||||
$ nix-build -A perlPackages.ClassC3
|
||||
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
|
||||
</screen>
|
||||
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the
|
||||
start of the name attribute, so the package above is actually called
|
||||
<literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
|
||||
<screen>
|
||||
$ nix-env -i perl-Class-C3
|
||||
<prompt>$ </prompt>nix-env -i perl-Class-C3
|
||||
</screen>
|
||||
(Of course you can also install using the attribute name: <literal>nix-env -i
|
||||
-A perlPackages.ClassC3</literal>.)
|
||||
@ -148,7 +148,7 @@ ClassC3Componentised = buildPerlPackage rec {
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
$ nix-env -i nix-generate-from-cpan
|
||||
<prompt>$ </prompt>nix-env -i nix-generate-from-cpan
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
@ -156,7 +156,7 @@ $ nix-env -i nix-generate-from-cpan
|
||||
unpacks the corresponding package, and prints a Nix expression on standard
|
||||
output. For example:
|
||||
<screen>
|
||||
$ nix-generate-from-cpan XML::Simple
|
||||
<prompt>$ </prompt>nix-generate-from-cpan XML::Simple
|
||||
XMLSimple = buildPerlPackage rec {
|
||||
name = "XML-Simple-2.22";
|
||||
src = fetchurl {
|
||||
|
||||
@ -30,7 +30,7 @@ meta = with stdenv.lib; {
|
||||
The meta-attributes of a package can be queried from the command-line using
|
||||
<command>nix-env</command>:
|
||||
<screen>
|
||||
$ nix-env -qa hello --json
|
||||
<prompt>$ </prompt>nix-env -qa hello --json
|
||||
{
|
||||
"hello": {
|
||||
"meta": {
|
||||
@ -70,7 +70,7 @@ $ nix-env -qa hello --json
|
||||
<command>nix-env</command> knows about the <varname>description</varname>
|
||||
field specifically:
|
||||
<screen>
|
||||
$ nix-env -qa hello --description
|
||||
<prompt>$ </prompt>nix-env -qa hello --description
|
||||
hello-2.3 A program that produces a familiar, friendly greeting
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
@ -92,9 +92,9 @@ modulesTree = [kernel]
|
||||
<para>
|
||||
If needed you can also run <literal>make menuconfig</literal>:
|
||||
<screen>
|
||||
$ nix-env -i ncurses
|
||||
$ export NIX_CFLAGS_LINK=-lncurses
|
||||
$ make menuconfig ARCH=<replaceable>arch</replaceable></screen>
|
||||
<prompt>$ </prompt>nix-env -i ncurses
|
||||
<prompt>$ </prompt>export NIX_CFLAGS_LINK=-lncurses
|
||||
<prompt>$ </prompt>make menuconfig ARCH=<replaceable>arch</replaceable></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -142,8 +142,8 @@ $ make menuconfig ARCH=<replaceable>arch</replaceable></screen>
|
||||
<para>
|
||||
The generator is invoked as follows:
|
||||
<screen>
|
||||
$ cd pkgs/servers/x11/xorg
|
||||
$ cat tarballs-7.5.list extra.list old.list \
|
||||
<prompt>$ </prompt>cd pkgs/servers/x11/xorg
|
||||
<prompt>$ </prompt>cat tarballs-7.5.list extra.list old.list \
|
||||
| perl ./generate-expr-from-tarballs.pl
|
||||
</screen>
|
||||
For each of the tarballs in the <filename>.list</filename> files, the script
|
||||
@ -160,8 +160,8 @@ $ cat tarballs-7.5.list extra.list old.list \
|
||||
A file like <filename>tarballs-7.5.list</filename> contains all tarballs in
|
||||
a X.org release. It can be generated like this:
|
||||
<screen>
|
||||
$ export i="mirror://xorg/X11R7.4/src/everything/"
|
||||
$ cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
|
||||
<prompt>$ </prompt>export i="mirror://xorg/X11R7.4/src/everything/"
|
||||
<prompt>$ </prompt>cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
|
||||
| perl -e 'while (<>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'i'}$2\n"; }; }' \
|
||||
| sort > tarballs-7.4.list
|
||||
</screen>
|
||||
@ -210,7 +210,7 @@ $ cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
|
||||
often available. It is possible to list available Eclipse packages by
|
||||
issuing the command:
|
||||
<screen>
|
||||
$ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
|
||||
<prompt>$ </prompt>nix-env -f '<nixpkgs>' -qaP -A eclipses --description
|
||||
</screen>
|
||||
Once an Eclipse variant is installed it can be run using the
|
||||
<command>eclipse</command> command, as expected. From within Eclipse it is
|
||||
@ -250,7 +250,7 @@ packageOverrides = pkgs: {
|
||||
available for installation using <varname>eclipseWithPlugins</varname> by
|
||||
running
|
||||
<screen>
|
||||
$ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
|
||||
<prompt>$ </prompt>nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
@ -9,8 +9,8 @@
|
||||
<para>
|
||||
Checkout the Nixpkgs source tree:
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nixpkgs
|
||||
$ cd nixpkgs</screen>
|
||||
<prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs
|
||||
<prompt>$ </prompt>cd nixpkgs</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -23,7 +23,7 @@ $ cd nixpkgs</screen>
|
||||
See <xref linkend="sec-organisation" /> for some hints on the tree
|
||||
organisation. Create a directory for your package, e.g.
|
||||
<screen>
|
||||
$ mkdir pkgs/development/libraries/libfoo</screen>
|
||||
<prompt>$ </prompt>mkdir pkgs/development/libraries/libfoo</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -34,8 +34,8 @@ $ mkdir pkgs/development/libraries/libfoo</screen>
|
||||
as arguments, and returns a build of the package in the Nix store. The
|
||||
expression should usually be called <filename>default.nix</filename>.
|
||||
<screen>
|
||||
$ emacs pkgs/development/libraries/libfoo/default.nix
|
||||
$ git add pkgs/development/libraries/libfoo/default.nix</screen>
|
||||
<prompt>$ </prompt>emacs pkgs/development/libraries/libfoo/default.nix
|
||||
<prompt>$ </prompt>git add pkgs/development/libraries/libfoo/default.nix</screen>
|
||||
</para>
|
||||
<para>
|
||||
You can have a look at the existing Nix expressions under
|
||||
@ -180,7 +180,7 @@ $ git add pkgs/development/libraries/libfoo/default.nix</screen>
|
||||
with some descriptive name for the variable, e.g.
|
||||
<varname>libfoo</varname>.
|
||||
<screen>
|
||||
$ emacs pkgs/top-level/all-packages.nix</screen>
|
||||
<prompt>$ </prompt>emacs pkgs/top-level/all-packages.nix</screen>
|
||||
</para>
|
||||
<para>
|
||||
The attributes in that file are sorted by category (like “Development /
|
||||
@ -193,7 +193,7 @@ $ emacs pkgs/top-level/all-packages.nix</screen>
|
||||
To test whether the package builds, run the following command from the
|
||||
root of the nixpkgs source tree:
|
||||
<screen>
|
||||
$ nix-build -A libfoo</screen>
|
||||
<prompt>$ </prompt>nix-build -A libfoo</screen>
|
||||
where <varname>libfoo</varname> should be the variable name defined in the
|
||||
previous step. You may want to add the flag <option>-K</option> to keep
|
||||
the temporary build directory in case something fails. If the build
|
||||
@ -205,7 +205,7 @@ $ nix-build -A libfoo</screen>
|
||||
<para>
|
||||
If you want to install the package into your profile (optional), do
|
||||
<screen>
|
||||
$ nix-env -f . -iA libfoo</screen>
|
||||
<prompt>$ </prompt>nix-env -f . -iA libfoo</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
||||
@ -153,11 +153,11 @@
|
||||
nixpkgs-unstable for easier review by running the following commands
|
||||
from a nixpkgs clone.
|
||||
<screen>
|
||||
$ git remote add channels https://github.com/NixOS/nixpkgs-channels.git <co
|
||||
<prompt>$ </prompt>git remote add channels https://github.com/NixOS/nixpkgs-channels.git <co
|
||||
xml:id='reviewing-rebase-1' />
|
||||
$ git fetch channels nixos-unstable <co xml:id='reviewing-rebase-2' />
|
||||
$ git fetch origin pull/PRNUMBER/head <co xml:id='reviewing-rebase-3' />
|
||||
$ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
|
||||
<prompt>$ </prompt>git fetch channels nixos-unstable <co xml:id='reviewing-rebase-2' />
|
||||
<prompt>$ </prompt>git fetch origin pull/PRNUMBER/head <co xml:id='reviewing-rebase-3' />
|
||||
<prompt>$ </prompt>git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
|
||||
xml:id='reviewing-rebase-4' />
|
||||
</screen>
|
||||
<calloutlist>
|
||||
@ -197,7 +197,7 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
|
||||
request url.
|
||||
</para>
|
||||
<screen>
|
||||
$ nix-shell -p nix-review --run "nix-review pr PRNUMBER"
|
||||
<prompt>$ </prompt>nix-shell -p nix-review --run "nix-review pr PRNUMBER"
|
||||
</screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -36,8 +36,8 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<screen>
|
||||
$ git checkout 0998212
|
||||
$ git checkout -b 'fix/pkg-name-update'
|
||||
<prompt>$ </prompt>git checkout 0998212
|
||||
<prompt>$ </prompt>git checkout -b 'fix/pkg-name-update'
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -11,12 +11,12 @@
|
||||
Nix’s <emphasis>garbage collector</emphasis> to remove old, unreferenced
|
||||
packages. This is easy:
|
||||
<screen>
|
||||
$ nix-collect-garbage
|
||||
<prompt>$ </prompt>nix-collect-garbage
|
||||
</screen>
|
||||
Alternatively, you can use a systemd unit that does the same in the
|
||||
background:
|
||||
<screen>
|
||||
# systemctl start nix-gc.service
|
||||
<prompt># </prompt>systemctl start nix-gc.service
|
||||
</screen>
|
||||
You can tell NixOS in <filename>configuration.nix</filename> to run this unit
|
||||
automatically at certain points in time, for instance, every night at 03:15:
|
||||
@ -31,11 +31,11 @@ $ nix-collect-garbage
|
||||
configurations. The following command deletes old roots, removing the ability
|
||||
to roll back to them:
|
||||
<screen>
|
||||
$ nix-collect-garbage -d
|
||||
<prompt>$ </prompt>nix-collect-garbage -d
|
||||
</screen>
|
||||
You can also do this for specific profiles, e.g.
|
||||
<screen>
|
||||
$ nix-env -p /nix/var/nix/profiles/per-user/eelco/profile --delete-generations old
|
||||
<prompt>$ </prompt>nix-env -p /nix/var/nix/profiles/per-user/eelco/profile --delete-generations old
|
||||
</screen>
|
||||
Note that NixOS system configurations are stored in the profile
|
||||
<filename>/nix/var/nix/profiles/system</filename>.
|
||||
@ -45,7 +45,7 @@ $ nix-env -p /nix/var/nix/profiles/per-user/eelco/profile --delete-generations o
|
||||
Nix store) is to run Nix’s store optimiser, which seeks out identical files
|
||||
in the store and replaces them with hard links to a single copy.
|
||||
<screen>
|
||||
$ nix-store --optimise
|
||||
<prompt>$ </prompt>nix-store --optimise
|
||||
</screen>
|
||||
Since this command needs to read the entire Nix store, it can take quite a
|
||||
while to finish.
|
||||
|
||||
@ -11,10 +11,10 @@
|
||||
<literal>10.233.0.0/16</literal>. You can get the container’s IPv4 address
|
||||
as follows:
|
||||
<screen>
|
||||
# nixos-container show-ip foo
|
||||
<prompt># </prompt>nixos-container show-ip foo
|
||||
10.233.4.2
|
||||
|
||||
$ ping -c1 10.233.4.2
|
||||
<prompt>$ </prompt>ping -c1 10.233.4.2
|
||||
64 bytes from 10.233.4.2: icmp_seq=1 ttl=64 time=0.106 ms
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
<literal>systemd</literal> hierarchy, which is what systemd uses to keep
|
||||
track of the processes belonging to each service or user session:
|
||||
<screen>
|
||||
$ systemd-cgls
|
||||
<prompt>$ </prompt>systemd-cgls
|
||||
├─user
|
||||
│ └─eelco
|
||||
│ └─c1
|
||||
|
||||
@ -11,14 +11,14 @@
|
||||
The command <literal>journalctl</literal> allows you to see the contents of
|
||||
the journal. For example,
|
||||
<screen>
|
||||
$ journalctl -b
|
||||
<prompt>$ </prompt>journalctl -b
|
||||
</screen>
|
||||
shows all journal entries since the last reboot. (The output of
|
||||
<command>journalctl</command> is piped into <command>less</command> by
|
||||
default.) You can use various options and match operators to restrict output
|
||||
to messages of interest. For instance, to get all messages from PostgreSQL:
|
||||
<screen>
|
||||
$ journalctl -u postgresql.service
|
||||
<prompt>$ </prompt>journalctl -u postgresql.service
|
||||
-- Logs begin at Mon, 2013-01-07 13:28:01 CET, end at Tue, 2013-01-08 01:09:57 CET. --
|
||||
...
|
||||
Jan 07 15:44:14 hagbard postgres[2681]: [2-1] LOG: database system is shut down
|
||||
@ -29,7 +29,7 @@ Jan 07 15:45:13 hagbard postgres[2500]: [1-1] LOG: database system is ready to
|
||||
Or to get all messages since the last reboot that have at least a
|
||||
“critical” severity level:
|
||||
<screen>
|
||||
$ journalctl -b -p crit
|
||||
<prompt>$ </prompt>journalctl -b -p crit
|
||||
Dec 17 21:08:06 mandark sudo[3673]: pam_unix(sudo:auth): auth could not identify password for [alice]
|
||||
Dec 29 01:30:22 mandark kernel[6131]: [1053513.909444] CPU6: Core temperature above threshold, cpu clock throttled (total events = 1)
|
||||
</screen>
|
||||
|
||||
@ -33,7 +33,7 @@
|
||||
where <replaceable>N</replaceable> is the number of the NixOS system
|
||||
configuration. To get a list of the available configurations, do:
|
||||
<screen>
|
||||
$ ls -l /nix/var/nix/profiles/system-*-link
|
||||
<prompt>$ </prompt>ls -l /nix/var/nix/profiles/system-*-link
|
||||
<replaceable>...</replaceable>
|
||||
lrwxrwxrwx 1 root root 78 Aug 12 13:54 /nix/var/nix/profiles/system-268-link -> /nix/store/202b...-nixos-13.07pre4932_5a676e4-4be1055
|
||||
</screen>
|
||||
|
||||
@ -21,7 +21,7 @@
|
||||
<command>systemd</command>. Without any arguments, it shows the status of
|
||||
active units:
|
||||
<screen>
|
||||
$ systemctl
|
||||
<prompt>$ </prompt>systemctl
|
||||
-.mount loaded active mounted /
|
||||
swapfile.swap loaded active active /swapfile
|
||||
sshd.service loaded active running SSH Daemon
|
||||
@ -33,7 +33,7 @@ graphical.target loaded active active Graphical Interface
|
||||
You can ask for detailed status information about a unit, for instance, the
|
||||
PostgreSQL database service:
|
||||
<screen>
|
||||
$ systemctl status postgresql.service
|
||||
<prompt>$ </prompt>systemctl status postgresql.service
|
||||
postgresql.service - PostgreSQL Server
|
||||
Loaded: loaded (/nix/store/pn3q73mvh75gsrl8w7fdlfk3fq5qm5mw-unit/postgresql.service)
|
||||
Active: active (running) since Mon, 2013-01-07 15:55:57 CET; 9h ago
|
||||
|
||||
@ -18,7 +18,7 @@
|
||||
If the corruption is in a path in the closure of the NixOS system
|
||||
configuration, you can fix it by doing
|
||||
<screen>
|
||||
# nixos-rebuild switch --repair
|
||||
<prompt># </prompt>nixos-rebuild switch --repair
|
||||
</screen>
|
||||
This will cause Nix to check every path in the closure, and if its
|
||||
cryptographic hash differs from the hash recorded in Nix’s database, the
|
||||
@ -28,7 +28,7 @@
|
||||
<para>
|
||||
You can also scan the entire Nix store for corrupt paths:
|
||||
<screen>
|
||||
# nix-store --verify --check-contents --repair
|
||||
<prompt># </prompt>nix-store --verify --check-contents --repair
|
||||
</screen>
|
||||
Any corrupt paths will be redownloaded if they’re available in a binary
|
||||
cache; otherwise, they cannot be repaired.
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
allows querying and manipulating user sessions. For instance, to list all
|
||||
user sessions:
|
||||
<screen>
|
||||
$ loginctl
|
||||
<prompt>$ </prompt>loginctl
|
||||
SESSION UID USER SEAT
|
||||
c1 500 eelco seat0
|
||||
c3 0 root seat0
|
||||
@ -21,7 +21,7 @@ $ loginctl
|
||||
devices attached to the system; usually, there is only one seat.) To get
|
||||
information about a session:
|
||||
<screen>
|
||||
$ loginctl session-status c3
|
||||
<prompt>$ </prompt>loginctl session-status c3
|
||||
c3 - root (0)
|
||||
Since: Tue, 2013-01-08 01:17:56 CET; 4min 42s ago
|
||||
Leader: 2536 (login)
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
With the command <command>nix-env</command>, you can install and uninstall
|
||||
packages from the command line. For instance, to install Mozilla Thunderbird:
|
||||
<screen>
|
||||
$ nix-env -iA nixos.thunderbird</screen>
|
||||
<prompt>$ </prompt>nix-env -iA nixos.thunderbird</screen>
|
||||
If you invoke this as root, the package is installed in the Nix profile
|
||||
<filename>/nix/var/nix/profiles/default</filename> and visible to all users
|
||||
of the system; otherwise, the package ends up in
|
||||
@ -25,7 +25,7 @@ $ nix-env -iA nixos.thunderbird</screen>
|
||||
Packages come from the NixOS channel. You typically upgrade a package by
|
||||
updating to the latest version of the NixOS channel:
|
||||
<screen>
|
||||
$ nix-channel --update nixos
|
||||
<prompt>$ </prompt>nix-channel --update nixos
|
||||
</screen>
|
||||
and then running <literal>nix-env -i</literal> again. Other packages in the
|
||||
profile are <emphasis>not</emphasis> affected; this is the crucial difference
|
||||
@ -34,21 +34,21 @@ $ nix-channel --update nixos
|
||||
their current versions in the NixOS channel. You can however upgrade all
|
||||
packages for which there is a newer version by doing:
|
||||
<screen>
|
||||
$ nix-env -u '*'
|
||||
<prompt>$ </prompt>nix-env -u '*'
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A package can be uninstalled using the <option>-e</option> flag:
|
||||
<screen>
|
||||
$ nix-env -e thunderbird
|
||||
<prompt>$ </prompt>nix-env -e thunderbird
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, you can roll back an undesirable <command>nix-env</command> action:
|
||||
<screen>
|
||||
$ nix-env --rollback
|
||||
<prompt>$ </prompt>nix-env --rollback
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
@ -14,8 +14,8 @@
|
||||
xlink:href="http://nixos.org/nixpkgs/manual">Nixpkgs
|
||||
manual</link>. In short, you clone Nixpkgs:
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nixpkgs
|
||||
$ cd nixpkgs
|
||||
<prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs
|
||||
<prompt>$ </prompt>cd nixpkgs
|
||||
</screen>
|
||||
Then you write and test the package as described in the Nixpkgs manual.
|
||||
Finally, you add it to <literal>environment.systemPackages</literal>, e.g.
|
||||
@ -65,8 +65,8 @@ stdenv.mkDerivation rec {
|
||||
</programlisting>
|
||||
This allows testing the package easily:
|
||||
<screen>
|
||||
$ nix-build my-hello.nix
|
||||
$ ./result/bin/hello
|
||||
<prompt>$ </prompt>nix-build my-hello.nix
|
||||
<prompt>$ </prompt>./result/bin/hello
|
||||
Hello, world!
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
<para>
|
||||
You can get a list of the available packages as follows:
|
||||
<screen>
|
||||
$ nix-env -qaP '*' --description
|
||||
<prompt>$ </prompt>nix-env -qaP '*' --description
|
||||
nixos.firefox firefox-23.0 Mozilla Firefox - the browser, reloaded
|
||||
<replaceable>...</replaceable>
|
||||
</screen>
|
||||
|
||||
@ -141,15 +141,15 @@ in {
|
||||
<option>services.matrix-synapse.registration_shared_secret</option>. To
|
||||
create a new user or admin, run the following after you have set the secret
|
||||
and have rebuilt NixOS:
|
||||
<programlisting>
|
||||
$ nix run nixpkgs.matrix-synapse
|
||||
$ register_new_matrix_user -k <your-registration-shared-secret> http://localhost:8008
|
||||
New user localpart: <your-username>
|
||||
Password:
|
||||
Confirm password:
|
||||
Make admin [no]:
|
||||
<screen>
|
||||
<prompt>$ </prompt>nix run nixpkgs.matrix-synapse
|
||||
<prompt>$ </prompt>register_new_matrix_user -k <replaceable>your-registration-shared-secret</replaceable> http://localhost:8008
|
||||
<prompt>New user localpart: </prompt><replaceable>your-username</replaceable>
|
||||
<prompt>Password:</prompt>
|
||||
<prompt>Confirm password:</prompt>
|
||||
<prompt>Make admin [no]:</prompt>
|
||||
Success!
|
||||
</programlisting>
|
||||
</screen>
|
||||
In the example, this would create a user with the Matrix Identifier
|
||||
<literal>@your-username:example.org</literal>. Note that the registration
|
||||
secret ends up in the nix store and therefore is world-readable by any user
|
||||
|
||||
@ -106,21 +106,21 @@ The unique option `services.httpd.adminAddr' is defined multiple times, in `/etc
|
||||
configuration option is. The command <option>nixos-option</option> allows you
|
||||
to find out:
|
||||
<screen>
|
||||
$ nixos-option <xref linkend="opt-services.xserver.enable"/>
|
||||
<prompt>$ </prompt>nixos-option <xref linkend="opt-services.xserver.enable"/>
|
||||
true
|
||||
|
||||
$ nixos-option <xref linkend="opt-boot.kernelModules"/>
|
||||
<prompt>$ </prompt>nixos-option <xref linkend="opt-boot.kernelModules"/>
|
||||
[ "tun" "ipv6" "loop" <replaceable>...</replaceable> ]
|
||||
</screen>
|
||||
Interactive exploration of the configuration is possible using <command>nix
|
||||
repl</command>, a read-eval-print loop for Nix expressions. A typical use:
|
||||
<screen>
|
||||
$ nix repl '<nixpkgs/nixos>'
|
||||
<prompt>$ </prompt>nix repl '<nixpkgs/nixos>'
|
||||
|
||||
nix-repl> config.<xref linkend="opt-networking.hostName"/>
|
||||
<prompt>nix-repl> </prompt>config.<xref linkend="opt-networking.hostName"/>
|
||||
"mandark"
|
||||
|
||||
nix-repl> map (x: x.hostName) config.<xref linkend="opt-services.httpd.virtualHosts"/>
|
||||
<prompt>nix-repl> </prompt>map (x: x.hostName) config.<xref linkend="opt-services.httpd.virtualHosts"/>
|
||||
[ "example.org" "example.gov" ]
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
@ -37,7 +37,7 @@
|
||||
If you are using WPA2 you can generate pskRaw key using
|
||||
<command>wpa_passphrase</command>:
|
||||
<screen>
|
||||
$ wpa_passphrase ESSID PSK
|
||||
<prompt>$ </prompt>wpa_passphrase ESSID PSK
|
||||
network={
|
||||
ssid="echelon"
|
||||
#psk="abcdefgh"
|
||||
@ -54,10 +54,10 @@ network={
|
||||
or you can use it to directly generate the
|
||||
<literal>wpa_supplicant.conf</literal>:
|
||||
<screen>
|
||||
# wpa_passphrase ESSID PSK > /etc/wpa_supplicant.conf</screen>
|
||||
<prompt># </prompt>wpa_passphrase ESSID PSK > /etc/wpa_supplicant.conf</screen>
|
||||
After you have edited the <literal>wpa_supplicant.conf</literal>, you need to
|
||||
restart the wpa_supplicant service.
|
||||
<screen>
|
||||
# systemctl restart wpa_supplicant.service</screen>
|
||||
<prompt># </prompt>systemctl restart wpa_supplicant.service</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
@ -64,7 +64,7 @@ Thunar:2410): GVFS-RemoteVolumeMonitor-WARNING **: remote volume monitor with db
|
||||
Session and Startup settings panel. Alternatively, you can run this command
|
||||
to do the same thing.
|
||||
<programlisting>
|
||||
$ xfconf-query -c xfce4-session -p /compat/LaunchGNOME -s true
|
||||
<prompt>$ </prompt>xfconf-query -c xfce4-session -p /compat/LaunchGNOME -s true
|
||||
</programlisting>
|
||||
A log-out and re-log will be needed for this to take effect.
|
||||
</para>
|
||||
|
||||
@ -14,14 +14,14 @@
|
||||
Default CD/DVD configurations are available inside
|
||||
<filename>nixos/modules/installer/cd-dvd</filename>.
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nixpkgs.git
|
||||
$ cd nixpkgs/nixos
|
||||
$ nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal.nix default.nix</screen>
|
||||
<prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs.git
|
||||
<prompt>$ </prompt>cd nixpkgs/nixos
|
||||
<prompt>$ </prompt>nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-minimal.nix default.nix</screen>
|
||||
</para>
|
||||
<para>
|
||||
Before burning your CD/DVD, you can check the content of the image by
|
||||
mounting anywhere like suggested by the following command:
|
||||
<screen>
|
||||
# mount -o loop -t iso9660 ./result/iso/cd.iso /mnt/iso</screen>
|
||||
<prompt># </prompt>mount -o loop -t iso9660 ./result/iso/cd.iso /mnt/iso</screen>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
@ -8,8 +8,8 @@
|
||||
With the command <command>nix-build</command>, you can build specific parts
|
||||
of your NixOS configuration. This is done as follows:
|
||||
<screen>
|
||||
$ cd <replaceable>/path/to/nixpkgs/nixos</replaceable>
|
||||
$ nix-build -A config.<replaceable>option</replaceable></screen>
|
||||
<prompt>$ </prompt>cd <replaceable>/path/to/nixpkgs/nixos</replaceable>
|
||||
<prompt>$ </prompt>nix-build -A config.<replaceable>option</replaceable></screen>
|
||||
where <replaceable>option</replaceable> is a NixOS option with type
|
||||
“derivation” (i.e. something that can be built). Attributes of interest
|
||||
include:
|
||||
@ -28,7 +28,7 @@ $ nix-build -A config.<replaceable>option</replaceable></screen>
|
||||
<para>
|
||||
A shortcut to build this is:
|
||||
<screen>
|
||||
$ nix-build -A system</screen>
|
||||
<prompt>$ </prompt>nix-build -A system</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -66,9 +66,9 @@ $ nix-build -A system</screen>
|
||||
test whether the kernel and the initial ramdisk boot correctly, by using
|
||||
QEMU’s <option>-kernel</option> and <option>-initrd</option> options:
|
||||
<screen>
|
||||
$ nix-build -A config.system.build.initialRamdisk -o initrd
|
||||
$ nix-build -A config.system.build.kernel -o kernel
|
||||
$ qemu-system-x86_64 -kernel ./kernel/bzImage -initrd ./initrd/initrd -hda /dev/null
|
||||
<prompt>$ </prompt>nix-build -A config.system.build.initialRamdisk -o initrd
|
||||
<prompt>$ </prompt>nix-build -A config.system.build.kernel -o kernel
|
||||
<prompt>$ </prompt>qemu-system-x86_64 -kernel ./kernel/bzImage -initrd ./initrd/initrd -hda /dev/null
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -99,15 +99,15 @@ $ qemu-system-x86_64 -kernel ./kernel/bzImage -initrd ./initrd/initrd -hda /dev/
|
||||
contain dots (e.g. <literal>httpd.service</literal>), you need to put
|
||||
them between quotes, like this:
|
||||
<screen>
|
||||
$ nix-build -A 'config.systemd.units."httpd.service".unit'
|
||||
<prompt>$ </prompt>nix-build -A 'config.systemd.units."httpd.service".unit'
|
||||
</screen>
|
||||
You can also test individual units, without rebuilding the whole system,
|
||||
by putting them in <filename>/run/systemd/system</filename>:
|
||||
<screen>
|
||||
$ cp $(nix-build -A 'config.systemd.units."httpd.service".unit')/httpd.service \
|
||||
<prompt>$ </prompt>cp $(nix-build -A 'config.systemd.units."httpd.service".unit')/httpd.service \
|
||||
/run/systemd/system/tmp-httpd.service
|
||||
# systemctl daemon-reload
|
||||
# systemctl start tmp-httpd.service
|
||||
<prompt># </prompt>systemctl daemon-reload
|
||||
<prompt># </prompt>systemctl start tmp-httpd.service
|
||||
</screen>
|
||||
Note that the unit must not have the same name as any unit in
|
||||
<filename>/etc/systemd/system</filename> since those take precedence over
|
||||
|
||||
@ -9,17 +9,17 @@
|
||||
The test itself can be run interactively. This is particularly useful when
|
||||
developing or debugging a test:
|
||||
<screen>
|
||||
$ nix-build nixos/tests/login.nix -A driver
|
||||
$ ./result/bin/nixos-test-driver
|
||||
<prompt>$ </prompt>nix-build nixos/tests/login.nix -A driver
|
||||
<prompt>$ </prompt>./result/bin/nixos-test-driver
|
||||
starting VDE switch for network 1
|
||||
>
|
||||
<prompt>></prompt>
|
||||
</screen>
|
||||
You can then take any Perl statement, e.g.
|
||||
<screen>
|
||||
> startAll
|
||||
> testScript
|
||||
> $machine->succeed("touch /tmp/foo")
|
||||
> print($machine->succeed("pwd")) # Show stdout of command
|
||||
<prompt>></prompt> startAll
|
||||
<prompt>></prompt> testScript
|
||||
<prompt>></prompt> $machine->succeed("touch /tmp/foo")
|
||||
<prompt>></prompt> print($machine->succeed("pwd")) # Show stdout of command
|
||||
</screen>
|
||||
The function <command>testScript</command> executes the entire test script
|
||||
and drops you back into the test driver command line upon its completion.
|
||||
@ -30,8 +30,8 @@ starting VDE switch for network 1
|
||||
<para>
|
||||
To just start and experiment with the VMs, run:
|
||||
<screen>
|
||||
$ nix-build nixos/tests/login.nix -A driver
|
||||
$ ./result/bin/nixos-run-vms
|
||||
<prompt>$ </prompt>nix-build nixos/tests/login.nix -A driver
|
||||
<prompt>$ </prompt>./result/bin/nixos-run-vms
|
||||
</screen>
|
||||
The script <command>nixos-run-vms</command> starts the virtual machines
|
||||
defined by test.
|
||||
|
||||
@ -12,12 +12,12 @@
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/login.nix">login.nix</filename>,
|
||||
you just do:
|
||||
<screen>
|
||||
$ nix-build '<nixpkgs/nixos/tests/login.nix>'
|
||||
<prompt>$ </prompt>nix-build '<nixpkgs/nixos/tests/login.nix>'
|
||||
</screen>
|
||||
or, if you don’t want to rely on <envar>NIX_PATH</envar>:
|
||||
<screen>
|
||||
$ cd /my/nixpkgs/nixos/tests
|
||||
$ nix-build login.nix
|
||||
<prompt>$ </prompt>cd /my/nixpkgs/nixos/tests
|
||||
<prompt>$ </prompt>nix-build login.nix
|
||||
…
|
||||
running the VM test script
|
||||
machine: QEMU running (pid 8841)
|
||||
@ -30,7 +30,7 @@ machine: QEMU running (pid 8841)
|
||||
fast, as no disk image needs to be created. Afterwards, you can view a
|
||||
pretty-printed log of the test:
|
||||
<screen>
|
||||
$ firefox result/log.html
|
||||
<prompt>$ </prompt>firefox result/log.html
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
@ -11,10 +11,10 @@
|
||||
modify NixOS, however, you should check out the latest sources from Git. This
|
||||
is as follows:
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nixpkgs
|
||||
$ cd nixpkgs
|
||||
$ git remote add channels https://github.com/NixOS/nixpkgs-channels
|
||||
$ git remote update channels
|
||||
<prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs
|
||||
<prompt>$ </prompt>cd nixpkgs
|
||||
<prompt>$ </prompt>git remote add channels https://github.com/NixOS/nixpkgs-channels
|
||||
<prompt>$ </prompt>git remote update channels
|
||||
</screen>
|
||||
This will check out the latest Nixpkgs sources to
|
||||
<filename>./nixpkgs</filename> the NixOS sources to
|
||||
@ -32,23 +32,23 @@ $ git remote update channels
|
||||
not have caught up yet and you’ll have to rebuild everything from source.
|
||||
So you may want to create a local branch based on your current NixOS version:
|
||||
<screen>
|
||||
$ nixos-version
|
||||
<prompt>$ </prompt>nixos-version
|
||||
17.09pre104379.6e0b727 (Hummingbird)
|
||||
|
||||
$ git checkout -b local 6e0b727
|
||||
<prompt>$ </prompt>git checkout -b local 6e0b727
|
||||
</screen>
|
||||
Or, to base your local branch on the latest version available in a NixOS
|
||||
channel:
|
||||
<screen>
|
||||
$ git remote update channels
|
||||
$ git checkout -b local channels/nixos-17.03
|
||||
<prompt>$ </prompt>git remote update channels
|
||||
<prompt>$ </prompt>git checkout -b local channels/nixos-17.03
|
||||
</screen>
|
||||
(Replace <literal>nixos-17.03</literal> with the name of the channel you want
|
||||
to use.) You can use <command>git merge</command> or <command>git
|
||||
rebase</command> to keep your local branch in sync with the channel, e.g.
|
||||
<screen>
|
||||
$ git remote update channels
|
||||
$ git merge channels/nixos-17.03
|
||||
<prompt>$ </prompt>git remote update channels
|
||||
<prompt>$ </prompt>git merge channels/nixos-17.03
|
||||
</screen>
|
||||
You can use <command>git cherry-pick</command> to copy commits from your
|
||||
local branch to the upstream branch.
|
||||
@ -58,7 +58,7 @@ $ git merge channels/nixos-17.03
|
||||
tell <command>nixos-rebuild</command> about them using the
|
||||
<option>-I</option> flag:
|
||||
<screen>
|
||||
# nixos-rebuild switch -I nixpkgs=<replaceable>/my/sources</replaceable>/nixpkgs
|
||||
<prompt># </prompt>nixos-rebuild switch -I nixpkgs=<replaceable>/my/sources</replaceable>/nixpkgs
|
||||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
@ -67,7 +67,7 @@ $ git merge channels/nixos-17.03
|
||||
<replaceable>/my/sources</replaceable>/nixpkgs</command>, or change the
|
||||
default by adding a symlink in <filename>~/.nix-defexpr</filename>:
|
||||
<screen>
|
||||
$ ln -s <replaceable>/my/sources</replaceable>/nixpkgs ~/.nix-defexpr/nixpkgs
|
||||
<prompt>$ </prompt>ln -s <replaceable>/my/sources</replaceable>/nixpkgs ~/.nix-defexpr/nixpkgs
|
||||
</screen>
|
||||
You may want to delete the symlink
|
||||
<filename>~/.nix-defexpr/channels_root</filename> to prevent root’s NixOS
|
||||
|
||||
@ -8,15 +8,15 @@
|
||||
Building, burning, and booting from an installation CD is rather tedious, so
|
||||
here is a quick way to see if the installer works properly:
|
||||
<screen>
|
||||
# mount -t tmpfs none /mnt
|
||||
# nixos-generate-config --root /mnt
|
||||
$ nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-install
|
||||
# ./result/bin/nixos-install</screen>
|
||||
<prompt># </prompt>mount -t tmpfs none /mnt
|
||||
<prompt># </prompt>nixos-generate-config --root /mnt
|
||||
<prompt>$ </prompt>nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-install
|
||||
<prompt># </prompt>./result/bin/nixos-install</screen>
|
||||
To start a login shell in the new NixOS installation in
|
||||
<filename>/mnt</filename>:
|
||||
<screen>
|
||||
$ nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-enter
|
||||
# ./result/bin/nixos-enter
|
||||
<prompt>$ </prompt>nix-build '<nixpkgs/nixos>' -A config.system.build.nixos-enter
|
||||
<prompt># </prompt>./result/bin/nixos-enter
|
||||
</screen>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
@ -15,16 +15,16 @@
|
||||
<note>
|
||||
<title>On macOS</title>
|
||||
<para>
|
||||
<programlisting>
|
||||
$ diskutil list
|
||||
<screen>
|
||||
<prompt>$ </prompt>diskutil list
|
||||
[..]
|
||||
/dev/diskN (external, physical):
|
||||
#: TYPE NAME SIZE IDENTIFIER
|
||||
[..]
|
||||
$ diskutil unmountDisk diskN
|
||||
<prompt>$ </prompt>diskutil unmountDisk diskN
|
||||
Unmount of all volumes on diskN was successful
|
||||
$ sudo dd if=nix.iso of=/dev/rdiskN
|
||||
</programlisting>
|
||||
<prompt>$ </prompt>sudo dd if=nix.iso of=/dev/rdiskN
|
||||
</screen>
|
||||
Using the 'raw' <command>rdiskN</command> device instead of
|
||||
<command>diskN</command> completes in minutes instead of hours. After
|
||||
<command>dd</command> completes, a GUI dialog "The disk you inserted was
|
||||
|
||||
@ -110,7 +110,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Create a <emphasis>GPT</emphasis> partition table.
|
||||
<screen language="commands"># parted /dev/sda -- mklabel gpt</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mklabel gpt</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -118,14 +118,14 @@
|
||||
Add the <emphasis>root</emphasis> partition. This will fill the disk
|
||||
except for the end part, where the swap will live, and the space left in
|
||||
front (512MiB) which will be used by the boot partition.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary 512MiB -8GiB</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mkpart primary 512MiB -8GiB</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Next, add a <emphasis>swap</emphasis> partition. The size required will
|
||||
vary according to needs, here a 8GiB one is created.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<note>
|
||||
<para>
|
||||
The swap partition size rules are no different than for other Linux
|
||||
@ -140,8 +140,8 @@
|
||||
the ESP (EFI system partition) as its <emphasis>/boot</emphasis>
|
||||
partition. It uses the initially reserved 512MiB at the start of the
|
||||
disk.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart ESP fat32 1MiB 512MiB
|
||||
# parted /dev/sda -- set 3 boot on</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mkpart ESP fat32 1MiB 512MiB
|
||||
<prompt># </prompt>parted /dev/sda -- set 3 boot on</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
@ -172,21 +172,21 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Create a <emphasis>MBR</emphasis> partition table.
|
||||
<screen language="commands"># parted /dev/sda -- mklabel msdos</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mklabel msdos</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Add the <emphasis>root</emphasis> partition. This will fill the the disk
|
||||
except for the end part, where the swap will live.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary 1MiB -8GiB</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mkpart primary 1MiB -8GiB</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Finally, add a <emphasis>swap</emphasis> partition. The size required
|
||||
will vary according to needs, here a 8GiB one is created.
|
||||
<screen language="commands"># parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<screen language="commands"><prompt># </prompt>parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<note>
|
||||
<para>
|
||||
The swap partition size rules are no different than for other Linux
|
||||
@ -218,7 +218,7 @@
|
||||
since this makes the file system configuration independent from device
|
||||
changes. For example:
|
||||
<screen>
|
||||
# mkfs.ext4 -L nixos /dev/sda1</screen>
|
||||
<prompt># </prompt>mkfs.ext4 -L nixos /dev/sda1</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -227,7 +227,7 @@
|
||||
recommended to assign a label to the swap partition: <option>-L
|
||||
<replaceable>label</replaceable></option>. For example:
|
||||
<screen>
|
||||
# mkswap -L swap /dev/sda2</screen>
|
||||
<prompt># </prompt>mkswap -L swap /dev/sda2</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -242,7 +242,7 @@
|
||||
it’s recommended to assign a label to the boot partition:
|
||||
<option>-n <replaceable>label</replaceable></option>. For example:
|
||||
<screen>
|
||||
# mkfs.fat -F 32 -n boot /dev/sda3</screen>
|
||||
<prompt># </prompt>mkfs.fat -F 32 -n boot /dev/sda3</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -273,7 +273,7 @@
|
||||
Mount the target file system on which NixOS should be installed on
|
||||
<filename>/mnt</filename>, e.g.
|
||||
<screen>
|
||||
# mount /dev/disk/by-label/nixos /mnt
|
||||
<prompt># </prompt>mount /dev/disk/by-label/nixos /mnt
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -287,8 +287,8 @@
|
||||
<para>
|
||||
Mount the boot file system on <filename>/mnt/boot</filename>, e.g.
|
||||
<screen>
|
||||
# mkdir -p /mnt/boot
|
||||
# mount /dev/disk/by-label/boot /mnt/boot
|
||||
<prompt># </prompt>mkdir -p /mnt/boot
|
||||
<prompt># </prompt>mount /dev/disk/by-label/boot /mnt/boot
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -303,7 +303,7 @@
|
||||
the build actions that it may spawn) may need quite a bit of RAM,
|
||||
depending on your configuration.
|
||||
<screen>
|
||||
# swapon /dev/sda2</screen>
|
||||
<prompt># </prompt>swapon /dev/sda2</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -325,11 +325,11 @@
|
||||
The command <command>nixos-generate-config</command> can generate an
|
||||
initial configuration file for you:
|
||||
<screen>
|
||||
# nixos-generate-config --root /mnt</screen>
|
||||
<prompt># </prompt>nixos-generate-config --root /mnt</screen>
|
||||
You should then edit <filename>/mnt/etc/nixos/configuration.nix</filename>
|
||||
to suit your needs:
|
||||
<screen>
|
||||
# nano /mnt/etc/nixos/configuration.nix
|
||||
<prompt># </prompt>nano /mnt/etc/nixos/configuration.nix
|
||||
</screen>
|
||||
If you’re using the graphical ISO image, other editors may be available
|
||||
(such as <command>vim</command>). If you have network access, you can also
|
||||
@ -412,7 +412,7 @@
|
||||
<para>
|
||||
Do the installation:
|
||||
<screen>
|
||||
# nixos-install</screen>
|
||||
<prompt># </prompt>nixos-install</screen>
|
||||
Cross fingers. If this fails due to a temporary problem (such as a network
|
||||
issue while downloading binaries from the NixOS binary cache), you can
|
||||
just re-run <command>nixos-install</command>. Otherwise, fix your
|
||||
@ -439,7 +439,7 @@ Retype new UNIX password: ***</screen>
|
||||
<para>
|
||||
If everything went well:
|
||||
<screen>
|
||||
# reboot</screen>
|
||||
<prompt># </prompt>reboot</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -460,16 +460,16 @@ Retype new UNIX password: ***</screen>
|
||||
You’ll probably want to create some user accounts as well, which can be
|
||||
done with <command>useradd</command>:
|
||||
<screen>
|
||||
$ useradd -c 'Eelco Dolstra' -m eelco
|
||||
$ passwd eelco</screen>
|
||||
<prompt>$ </prompt>useradd -c 'Eelco Dolstra' -m eelco
|
||||
<prompt>$ </prompt>passwd eelco</screen>
|
||||
</para>
|
||||
<para>
|
||||
You may also want to install some software. For instance,
|
||||
<screen>
|
||||
$ nix-env -qa \*</screen>
|
||||
<prompt>$ </prompt>nix-env -qa \*</screen>
|
||||
shows what packages are available, and
|
||||
<screen>
|
||||
$ nix-env -i w3m</screen>
|
||||
<prompt>$ </prompt>nix-env -i w3m</screen>
|
||||
install the <literal>w3m</literal> browser.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -489,19 +489,19 @@ $ nix-env -i w3m</screen>
|
||||
<example xml:id="ex-partition-scheme-MBR">
|
||||
<title>Example partition schemes for NixOS on <filename>/dev/sda</filename> (MBR)</title>
|
||||
<screen language="commands">
|
||||
# parted /dev/sda -- mklabel msdos
|
||||
# parted /dev/sda -- mkpart primary 1MiB -8GiB
|
||||
# parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
<prompt># </prompt>parted /dev/sda -- mklabel msdos
|
||||
<prompt># </prompt>parted /dev/sda -- mkpart primary 1MiB -8GiB
|
||||
<prompt># </prompt>parted /dev/sda -- mkpart primary linux-swap -8GiB 100%</screen>
|
||||
</example>
|
||||
|
||||
<example xml:id="ex-partition-scheme-UEFI">
|
||||
<title>Example partition schemes for NixOS on <filename>/dev/sda</filename> (UEFI)</title>
|
||||
<screen language="commands">
|
||||
# parted /dev/sda -- mklabel gpt
|
||||
# parted /dev/sda -- mkpart primary 512MiB -8GiB
|
||||
# parted /dev/sda -- mkpart primary linux-swap -8GiB 100%
|
||||
# parted /dev/sda -- mkpart ESP fat32 1MiB 512MiB
|
||||
# parted /dev/sda -- set 3 boot on</screen>
|
||||
<prompt># </prompt>parted /dev/sda -- mklabel gpt
|
||||
<prompt># </prompt>parted /dev/sda -- mkpart primary 512MiB -8GiB
|
||||
<prompt># </prompt>parted /dev/sda -- mkpart primary linux-swap -8GiB 100%
|
||||
<prompt># </prompt>parted /dev/sda -- mkpart ESP fat32 1MiB 512MiB
|
||||
<prompt># </prompt>parted /dev/sda -- set 3 boot on</screen>
|
||||
</example>
|
||||
|
||||
<example xml:id="ex-install-sequence">
|
||||
@ -509,17 +509,17 @@ $ nix-env -i w3m</screen>
|
||||
<para>
|
||||
With a partitioned disk.
|
||||
<screen language="commands">
|
||||
# mkfs.ext4 -L nixos /dev/sda1
|
||||
# mkswap -L swap /dev/sda2
|
||||
# swapon /dev/sda2
|
||||
# mkfs.fat -F 32 -n boot /dev/sda3 # <lineannotation>(for UEFI systems only)</lineannotation>
|
||||
# mount /dev/disk/by-label/nixos /mnt
|
||||
# mkdir -p /mnt/boot # <lineannotation>(for UEFI systems only)</lineannotation>
|
||||
# mount /dev/disk/by-label/boot /mnt/boot # <lineannotation>(for UEFI systems only)</lineannotation>
|
||||
# nixos-generate-config --root /mnt
|
||||
# nano /mnt/etc/nixos/configuration.nix
|
||||
# nixos-install
|
||||
# reboot</screen>
|
||||
<prompt># </prompt>mkfs.ext4 -L nixos /dev/sda1
|
||||
<prompt># </prompt>mkswap -L swap /dev/sda2
|
||||
<prompt># </prompt>swapon /dev/sda2
|
||||
<prompt># </prompt>mkfs.fat -F 32 -n boot /dev/sda3 # <lineannotation>(for UEFI systems only)</lineannotation>
|
||||
<prompt># </prompt>mount /dev/disk/by-label/nixos /mnt
|
||||
<prompt># </prompt>mkdir -p /mnt/boot # <lineannotation>(for UEFI systems only)</lineannotation>
|
||||
<prompt># </prompt>mount /dev/disk/by-label/boot /mnt/boot # <lineannotation>(for UEFI systems only)</lineannotation>
|
||||
<prompt># </prompt>nixos-generate-config --root /mnt
|
||||
<prompt># </prompt>nano /mnt/etc/nixos/configuration.nix
|
||||
<prompt># </prompt>nixos-install
|
||||
<prompt># </prompt>reboot</screen>
|
||||
</para>
|
||||
</example>
|
||||
|
||||
|
||||
@ -154,7 +154,7 @@
|
||||
file systems on <filename>/mnt</filename> and
|
||||
<filename>/mnt/boot</filename>, you would run:
|
||||
<screen>
|
||||
$ nixos-generate-config --root /mnt
|
||||
<prompt>$ </prompt>nixos-generate-config --root /mnt
|
||||
</screen>
|
||||
The resulting file
|
||||
<filename>/mnt/etc/nixos/hardware-configuration.nix</filename> might look
|
||||
@ -204,7 +204,7 @@ $ nixos-generate-config --root /mnt
|
||||
<para>
|
||||
After installation, if your hardware configuration changes, you can run:
|
||||
<screen>
|
||||
$ nixos-generate-config
|
||||
<prompt>$ </prompt>nixos-generate-config
|
||||
</screen>
|
||||
to update <filename>/etc/nixos/hardware-configuration.nix</filename>. Your
|
||||
<filename>/etc/nixos/configuration.nix</filename> will
|
||||
|
||||
@ -255,12 +255,12 @@
|
||||
on an <literal>ext4</literal> file system created in
|
||||
<filename>/dev/sda1</filename>:
|
||||
<screen>
|
||||
$ mkfs.ext4 /dev/sda1
|
||||
$ mount /dev/sda1 /mnt
|
||||
$ nixos-generate-config --root /mnt
|
||||
$ # edit /mnt/etc/nixos/configuration.nix
|
||||
$ nixos-install
|
||||
$ reboot
|
||||
<prompt>$ </prompt>mkfs.ext4 /dev/sda1
|
||||
<prompt>$ </prompt>mount /dev/sda1 /mnt
|
||||
<prompt>$ </prompt>nixos-generate-config --root /mnt
|
||||
<prompt>$ </prompt># edit /mnt/etc/nixos/configuration.nix
|
||||
<prompt>$ </prompt>nixos-install
|
||||
<prompt>$ </prompt>reboot
|
||||
</screen>
|
||||
</para>
|
||||
</refsection>
|
||||
|
||||
@ -103,13 +103,13 @@
|
||||
<title>Examples</title>
|
||||
<para>
|
||||
Investigate option values:
|
||||
<screen>$ nixos-option boot.loader
|
||||
<screen><prompt>$ </prompt>nixos-option boot.loader
|
||||
This attribute set contains:
|
||||
generationsDir
|
||||
grub
|
||||
initScript
|
||||
|
||||
$ nixos-option boot.loader.grub.enable
|
||||
<prompt>$ </prompt>nixos-option boot.loader.grub.enable
|
||||
Value:
|
||||
true
|
||||
|
||||
|
||||
@ -160,7 +160,7 @@
|
||||
the current directory, which points to the output of the top-level
|
||||
“system” derivation. This is essentially the same as doing
|
||||
<screen>
|
||||
$ nix-build /path/to/nixpkgs/nixos -A system
|
||||
<prompt>$ </prompt>nix-build /path/to/nixpkgs/nixos -A system
|
||||
</screen>
|
||||
Note that you do not need to be <literal>root</literal> to run
|
||||
<command>nixos-rebuild build</command>.
|
||||
@ -215,8 +215,8 @@ $ nix-build /path/to/nixpkgs/nixos -A system
|
||||
at the script that starts the VM. Thus, to test a NixOS configuration in
|
||||
a virtual machine, you should do the following:
|
||||
<screen>
|
||||
$ nixos-rebuild build-vm
|
||||
$ ./result/bin/run-*-vm
|
||||
<prompt>$ </prompt>nixos-rebuild build-vm
|
||||
<prompt>$ </prompt>./result/bin/run-*-vm
|
||||
</screen>
|
||||
</para>
|
||||
<para>
|
||||
@ -375,7 +375,7 @@ $ ./result/bin/run-*-vm
|
||||
<filename>test.nix</filename> without affecting the default system
|
||||
profile, you would do:
|
||||
<screen>
|
||||
$ nixos-rebuild switch -p test -I nixos-config=./test.nix
|
||||
<prompt>$ </prompt>nixos-rebuild switch -p test -I nixos-config=./test.nix
|
||||
</screen>
|
||||
The new configuration will appear in the GRUB 2 submenu “NixOS -
|
||||
Profile 'test'”.
|
||||
|
||||
@ -627,7 +627,7 @@ nix-env -f "<nixpkgs>" -iA haskellPackages.pandoc
|
||||
In case of an infinite loop, use the <command>--show-trace</command>
|
||||
command line argument and read the line just above the error message.
|
||||
<screen>
|
||||
$ nixos-rebuild build --show-trace
|
||||
<prompt>$ </prompt>nixos-rebuild build --show-trace
|
||||
…
|
||||
while evaluating the module argument `pkgs' in "/etc/nixos/my-module.nix":
|
||||
infinite recursion encountered
|
||||
|
||||
@ -47,14 +47,14 @@ services.foundationdb.package = pkgs.foundationdb52; # FoundationDB 5.2.x
|
||||
After running <command>nixos-rebuild</command>, you can verify whether
|
||||
FoundationDB is running by executing <command>fdbcli</command> (which is
|
||||
added to <option>environment.systemPackages</option>):
|
||||
<programlisting>
|
||||
$ sudo -u foundationdb fdbcli
|
||||
<screen>
|
||||
<prompt>$ </prompt>sudo -u foundationdb fdbcli
|
||||
Using cluster file `/etc/foundationdb/fdb.cluster'.
|
||||
|
||||
The database is available.
|
||||
|
||||
Welcome to the fdbcli. For help, type `help'.
|
||||
fdb> status
|
||||
<prompt>fdb> </prompt>status
|
||||
|
||||
Using cluster file `/etc/foundationdb/fdb.cluster'.
|
||||
|
||||
@ -72,8 +72,8 @@ Cluster:
|
||||
|
||||
...
|
||||
|
||||
fdb>
|
||||
</programlisting>
|
||||
<prompt>fdb></prompt>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -82,8 +82,8 @@ fdb>
|
||||
cluster status, as a quick example. (This example uses
|
||||
<command>nix-shell</command> shebang support to automatically supply the
|
||||
necessary Python modules).
|
||||
<programlisting>
|
||||
a@link> cat fdb-status.py
|
||||
<screen>
|
||||
<prompt>a@link> </prompt>cat fdb-status.py
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i python -p python pythonPackages.foundationdb52
|
||||
|
||||
@ -103,11 +103,11 @@ def main():
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
a@link> chmod +x fdb-status.py
|
||||
a@link> ./fdb-status.py
|
||||
<prompt>a@link> </prompt>chmod +x fdb-status.py
|
||||
<prompt>a@link> </prompt>./fdb-status.py
|
||||
FoundationDB available: True
|
||||
a@link>
|
||||
</programlisting>
|
||||
<prompt>a@link></prompt>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -266,10 +266,10 @@ services.foundationdb.dataDir = "/data/fdb";
|
||||
<emphasis>every</emphasis> node a coordinator automatically:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
fdbcli> configure double ssd
|
||||
fdbcli> coordinators auto
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>fdbcli> </prompt>configure double ssd
|
||||
<prompt>fdbcli> </prompt>coordinators auto
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
This will transparently update all the servers within seconds, and
|
||||
@ -386,10 +386,10 @@ services.foundationdb.extraReadWritePaths = [ "/opt/fdb-backups" ];
|
||||
You can now perform a backup:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ sudo -u foundationdb fdbbackup start -t default -d file:///opt/fdb-backups
|
||||
$ sudo -u foundationdb fdbbackup status -t default
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>sudo -u foundationdb fdbbackup start -t default -d file:///opt/fdb-backups
|
||||
<prompt>$ </prompt>sudo -u foundationdb fdbbackup status -t default
|
||||
</screen>
|
||||
</section>
|
||||
<section xml:id="module-services-foundationdb-limitations">
|
||||
<title>Known limitations</title>
|
||||
|
||||
@ -42,11 +42,11 @@
|
||||
whether PostgreSQL works by running <command>psql</command>:
|
||||
|
||||
<screen>
|
||||
$ psql
|
||||
<prompt>$ </prompt>psql
|
||||
psql (9.2.9)
|
||||
Type "help" for help.
|
||||
|
||||
alice=>
|
||||
<prompt>alice=></prompt>
|
||||
</screen>
|
||||
-->
|
||||
|
||||
|
||||
@ -238,8 +238,8 @@ in
|
||||
<para>
|
||||
You can check that it works by executing this in a terminal:
|
||||
<screen>
|
||||
$ nix-build emacs.nix
|
||||
$ ./result/bin/emacs -q
|
||||
<prompt>$ </prompt>nix-build emacs.nix
|
||||
<prompt>$ </prompt>./result/bin/emacs -q
|
||||
</screen>
|
||||
and then typing <literal>M-x package-initialize</literal>. Check that you
|
||||
can use all the packages you want in this Emacs instance. For example, try
|
||||
@ -403,9 +403,9 @@ in [...]
|
||||
<para>
|
||||
To start the daemon, execute the following:
|
||||
<screen>
|
||||
$ nixos-rebuild switch # to activate the new configuration.nix
|
||||
$ systemctl --user daemon-reload # to force systemd reload
|
||||
$ systemctl --user start emacs.service # to start the Emacs daemon
|
||||
<prompt>$ </prompt>nixos-rebuild switch # to activate the new configuration.nix
|
||||
<prompt>$ </prompt>systemctl --user daemon-reload # to force systemd reload
|
||||
<prompt>$ </prompt>systemctl --user start emacs.service # to start the Emacs daemon
|
||||
</screen>
|
||||
The server should now be ready to serve Emacs clients.
|
||||
</para>
|
||||
|
||||
@ -138,13 +138,13 @@ services.gitlab = {
|
||||
|
||||
<para>
|
||||
For example, to backup a Gitlab instance:
|
||||
<programlisting>
|
||||
$ sudo -u git -H gitlab-rake gitlab:backup:create
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>sudo -u git -H gitlab-rake gitlab:backup:create
|
||||
</screen>
|
||||
A list of all availabe rake tasks can be obtained by running:
|
||||
<programlisting>
|
||||
$ sudo -u git -H gitlab-rake -T
|
||||
</programlisting>
|
||||
<screen>
|
||||
<prompt>$ </prompt>sudo -u git -H gitlab-rake -T
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -105,7 +105,7 @@
|
||||
Now in order to import the <literal>alice</literal> user to another machine
|
||||
<literal>alicebox</literal>, all we need to do is something like this:
|
||||
<screen>
|
||||
$ ssh server nixos-taskserver user export my-company alice | sh
|
||||
<prompt>$ </prompt>ssh server nixos-taskserver user export my-company alice | sh
|
||||
</screen>
|
||||
Of course, if no SSH daemon is available on the server you can also copy
|
||||
& paste it directly into a shell.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user