65 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			65 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
<section xmlns="http://docbook.org/ns/docbook"
 | 
						||
        xmlns:xlink="http://www.w3.org/1999/xlink"
 | 
						||
        xmlns:xi="http://www.w3.org/2001/XInclude"
 | 
						||
        version="5.0"
 | 
						||
        xml:id="sec-boot-problems">
 | 
						||
 | 
						||
<title>Boot Problems</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:
 | 
						||
 | 
						||
<variablelist>
 | 
						||
 | 
						||
  <varlistentry><term><literal>boot.shell_on_fail</literal></term>
 | 
						||
    <listitem><para>Start a root shell if something goes wrong in
 | 
						||
    stage 1 of the boot process (the initial ramdisk).  This is
 | 
						||
    disabled by default because there is no authentication for the
 | 
						||
    root shell.</para></listitem>
 | 
						||
  </varlistentry>
 | 
						||
 | 
						||
  <varlistentry><term><literal>boot.debug1</literal></term>
 | 
						||
    <listitem><para>Start an interactive shell in stage 1 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></listitem>
 | 
						||
  </varlistentry>
 | 
						||
 | 
						||
  <varlistentry><term><literal>boot.trace</literal></term>
 | 
						||
    <listitem><para>Print every shell command executed by the stage 1
 | 
						||
    and 2 boot scripts.</para></listitem>
 | 
						||
  </varlistentry>
 | 
						||
 | 
						||
  <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>
 | 
						||
 | 
						||
For more parameters recognised by systemd, see
 | 
						||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
 | 
						||
 | 
						||
<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,
 | 
						||
this will start rescue mode (described above).  (Also note that since
 | 
						||
most units have a 90-second timeout before systemd gives up on them,
 | 
						||
the <command>agetty</command> login prompts should appear eventually
 | 
						||
unless something is very wrong.)</para>
 | 
						||
 | 
						||
</section> |