public/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update the troubleshooting section for systemd

Browse Source
This commit is contained in:
Eelco Dolstra 2013-01-09 13:43:57 +01:00
parent 19127aa416
commit b5e639dbb1
2 changed files with 46 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
doc/manual/troubleshooting.xml
View File

@ -4,36 +4,52 @@
<title>Troubleshooting</title> <title>Troubleshooting</title>
<section> <section><title>Boot problems</title>
<title>Debugging the boot process</title> <para>If NixOS fails to boot, there are a number of kernel command
line parameters that may help you to identify or fix the issue. You
can add these parameters in the GRUB boot menu by pressing “e” to
modify the selected boot entry and editing the line starting with
<literal>linux</literal>. The following are some useful kernel command
line parameters that are recognised by the NixOS boot scripts or by
systemd:
<para>To get a Stage 1 shell (i.e., a shell in the initial ramdisk), <variablelist>
add <literal>debug1</literal> to the kernel command line. The shell
gets started before anything useful has been done. That is, no
modules have been loaded and no file systems have been mounted, except
for <filename>/proc</filename> and <filename>/sys</filename>.</para>
<para>To get a Stage 2 shell (i.e., a shell in the actual root file <varlistentry><term><literal>debug1</literal></term>
system), add <literal>debug2</literal> to the kernel command <listitem><para>Request an interactive shell in stage 1 of the
line. This shell is started right after stage 1 calls the stage 2 boot process (the initial ramdisk). The shell gets started before
<literal>init</literal> script, so the root file system is there but anything useful has been done. That is, no modules have been
no services have been started.</para> loaded and no file systems have been mounted, except for
<filename>/proc</filename> and
<filename>/sys</filename>.</para></listitem>
</varlistentry>
</section> <varlistentry><term><literal>single</literal></term>
<listitem><para>Boot into rescue mode (a.k.a. single user mode).
This will cause systemd to start nothing but the unit
<literal>rescue.target</literal>, which runs
<command>sulogin</command> to prompt for the root password and
start a root login shell. Exiting the shell causes the system to
continue with the normal boot process.</para></listitem>
</varlistentry>
<varlistentry><term><literal>systemd.log_level=debug systemd.log_target=console</literal></term>
<listitem><para>Make systemd very verbose and send log messages to
the console instead of the journal.</para></listitem>
</varlistentry>
</variablelist>
<section> For more parameters recognised by systemd, see
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
<title>Safe mode</title> <para>If no login prompts or X11 login screens appear (e.g. due to
hanging dependencies), you can press Alt+ArrowUp. If you’re lucky,
<para>If the hardware autodetection (in this will start rescue mode (described above). (Also note that since
<filename>upstart-jobs/hardware-scan</filename>) causes problems, add most units have a 90-second timeout before systemd gives up on them,
<literal>safemode</literal> to the kernel command line. This will the <command>agetty</command> login prompts should appear eventually
disable auto-loading of modules for your PCI devices. However, you unless something is very wrong.)</para>
will probably need to explicitly add modules to
<option>boot.kernelModules</option> to get network support etc.</para>
</section> </section>
@ -42,22 +58,16 @@ will probably need to explicitly add modules to
<title>Maintenance mode</title> <title>Maintenance mode</title>
<para>You can go to maintenance mode by doing <para>You can enter rescue mode by running:
<screen> <screen>
$ shutdown now</screen> $ systemctl rescue</screen>
This will eventually give you a single-user root shell. This will eventually give you a single-user root shell. Systemd will
stop (almost) all system services. To get out of maintenance mode,
To get out of maintenance mode, do just exit from the rescue shell.</para>
<screen>
$ initctl emit startup</screen>
</para>
</section> </section>
</chapter> </chapter>