From 1f28e88fa41a1110c8f5ebfab1c4020d1e71d597 Mon Sep 17 00:00:00 2001
From: nthykier <nthykier@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Date: Sat, 28 Mar 2015 08:21:59 +0000
Subject: [PATCH] Upgrading: Document how to get a debug shell with systemd

Signed-off-by: Niels Thykier <niels@thykier.net>

git-svn-id: svn+ssh://svn.debian.org/svn/ddp/manuals/trunk/release-notes@10676 313b444b-1b9f-4f58-a734-7bb04f332e8d
---
 en/upgrading.dbk | 37 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 34b7b3a..0493bf6 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -189,7 +189,42 @@ course you will also need to fix the underlying problem and regenerate the
 initrd so the next boot won't fail again.
 </para>
 </section>
-
+<section id="recovery-shell-systemd">
+  <title>Debug shell during boot using systemd</title>
+  <para>
+    In case the boot fails under systemd, it is possible to obtain a
+    debug root shell by changing the kernel command line.  If the
+    basic boot succeeds, but some of the services fails to start, it
+    may be useful to add <literal>systemd.unit=rescue.target</literal>
+    to the kernel parameters.
+  </para>
+  <para>
+    Otherwise, the kernel parameter
+    <literal>systemd.unit=emergency.target</literal> will provide you
+    with a root shell at the earliest possible point.  However, this
+    is done before mounting the root file system with read-write
+    permissions.  You will have to do that manually with:
+  </para>
+  <screen>
+mount -o remount,rw /
+  </screen>
+  <para>
+    More information on debugging a broken boot under systemd
+    can be found in the <ulink
+    url="http://freedesktop.org/wiki/Software/systemd/Debugging/">
+    Diagnosing Boot Problems</ulink> article.
+  </para>
+  <!-- TODO: Presumably Jessie-only -->
+  <para>
+    If everything else fails, you might be able to boot via the old
+    sysvinit system.  This requires that <systemitem
+    role="package">sysvinit</systemitem> is still installed and the
+    binary <filename>/lib/sysvinit/init</filename> is included in your
+    initramfs.  If these requirements are met, add
+    <literal>init=/lib/sysvinit/init</literal> on the kernel
+    command-line and it will boot with the sysvinit binary.
+  </para>
+</section>
 </section>
 
 <section id="upgrade-preparations">
-- 
2.1.4