Browse Source

Manual: "filesystem" -> "file system"

nsd-state-dir
Eelco Dolstra 9 years ago
parent
commit
735ad3f466
  1. 18
      doc/manual/configuration.xml
  2. 25
      doc/manual/man-nixos-rebuild.xml
  3. 2
      doc/manual/running.xml

18
doc/manual/configuration.xml

@ -394,11 +394,11 @@ groups can be managed using <command>groupadd</command>,
<!--===============================================================-->
<section><title>Filesystems</title>
<section><title>File systems</title>
<para>You can define filesystems using the
<para>You can define file systems using the
<option>fileSystems</option> configuration option. For instance, the
following definition causes NixOS to mount the Ext4 filesystem on
following definition causes NixOS to mount the Ext4 file system on
device <filename>/dev/disk/by-label/data</filename> onto the mount
point <filename>/data</filename>:
@ -416,20 +416,20 @@ device aliases in <filename>/dev/disk/by-label</filename> and
topology changes (e.g. if a disk is moved to another IDE
controller).</para>
<para>You can usually omit the filesystem type
<para>You can usually omit the file system type
(<option>fsType</option>), since <command>mount</command> can usually
detect the type and load the necessary kernel module automatically.
However, if the filesystem is needed at early boot (in the initial
However, if the file system is needed at early boot (in the initial
ramdisk) and is not <literal>ext2</literal>, <literal>ext3</literal>
or <literal>ext4</literal>, then it’s best to specify
<option>fsType</option> to ensure that the kernel module is
available.</para>
<section><title>LUKS-encrypted filesystems</title>
<section><title>LUKS-encrypted file systems</title>
<para>NixOS supports filesystems that are encrypted using
<para>NixOS supports file systems that are encrypted using
<emphasis>LUKS</emphasis> (Linux Unified Key Setup). For example,
here is how you create an encrypted Ext4 filesystem on the device
here is how you create an encrypted Ext4 file system on the device
<filename>/dev/sda2</filename>:
<screen>
@ -449,7 +449,7 @@ Enter passphrase for /dev/sda2: ***
$ mkfs.ext4 /dev/mapper/crypted
</screen>
To ensure that this filesystem is automatically mounted at boot time
To ensure that this file system is automatically mounted at boot time
as <filename>/</filename>, add the following to
<filename>configuration.nix</filename>:

25
doc/manual/man-nixos-rebuild.xml

@ -133,22 +133,21 @@ $ ./result/bin/run-*-vm
<literal>kvm-intel</literal> or <literal>kvm-amd</literal>
kernel modules to get hardware virtualisation.</para>
<para>The VM mounts the Nix store of the host through the CIFS
filesystem. (<literal>qemu-kvm</literal> automatically starts a
Samba daemon for this purpose.) The host Nix store is
read-only, so Nix commands that modify the Nix store will not
work in the VM. This includes commands such as
<command>nixos-rebuild</command>; to change the VM’s
configuration, you must halt the VM and re-run the commands
above.
<para>The VM mounts the Nix store of the host through the 9P
file system. The host Nix store is read-only, so Nix commands
that modify the Nix store will not work in the VM. This
includes commands such as <command>nixos-rebuild</command>; to
change the VM’s configuration, you must halt the VM and re-run
the commands above.
</para>
<para>The VM has its own <literal>ext3</literal> root
filesystem, which is automatically created when the VM is first
<para>The VM has its own <literal>ext3</literal> root file
system, which is automatically created when the VM is first
started, and is persistent across reboots of the VM. It is
stored in <literal>./<replaceable>hostname</replaceable>.qcow2</literal>.
<!-- The entire filesystem hierarchy of the host is available in the
VM under <filename>/hostfs</filename>.--></para>
stored in
<literal>./<replaceable>hostname</replaceable>.qcow2</literal>.
<!-- The entire file system hierarchy of the host is available in
the VM under <filename>/hostfs</filename>.--></para>
</listitem>
</varlistentry>

2
doc/manual/running.xml

@ -23,7 +23,7 @@ instance, one unit can require that another unit must be successfully
started before the first unit can be started. When the system boots,
it starts a unit named <literal>default.target</literal>; the
dependencies of this unit cause all system services to be started,
filesystems to be mounted, swap files to be activated, and so
file systems to be mounted, swap files to be activated, and so
on.</para>
<para>The command <command>systemctl</command> is the main way to

Loading…
Cancel
Save