1 files changed, 112 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 0000000..11f5e32
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,112 @@
+Enabling persistent logging in journald
+=======================================
+
+To enable persistent logging, create /var/log/journal:
+
+  mkdir -p /var/log/journal
+  systemd-tmpfiles --create --prefix /var/log/journal
+
+systemd will make the journal files owned by the "systemd-journal" group and
+add an ACL for read permissions for users in the "adm" group.
+To grant a user read access to the system journal, add them to one of the two
+groups.
+
+This will allow you to look at previous boot logs with e. g.
+"journalctl -b -1".
+
+If you enable persistent logging, consider uninstalling rsyslog or any other
+system-log-daemon, to avoid logging everything twice.
+
+Debugging boot/shutdown problems
+================================
+
+The "debug-shell" service starts a root shell on VT 9 which is available very
+early during boot and very late during shutdown. You can temporarily enable
+this when booting the system does not get sufficiently far to get a desktop or
+even the text console logins (getty), or when shutdown hangs eternally.
+
+For boot problems the recommended way is to append "systemd.debug-shell" to the
+kernel command line in the bootloader.
+For shutdown problems, run "systemctl start debug-shell" as root, then shut
+down.
+
+WARNING: Please avoid "systemctl enable debug-shell" as this will start the
+debug shell permanently which is a SECURITY HOLE as it allows unauthenticated
+and unrestricted root access to your computer if you forget to disable it!
+Please only enable it if you cannot pass "systemd.debug-shell" to the boot
+loader for some reason, and then immediately run "systemctl disable debug-shell"
+after booting.
+
+Once the boot/shutdown problem happened, switch to VT9 (Ctrl+Alt+F9). There you
+can use the usual systemctl or journalctl commands, or any other Linux shell
+command to list or kill processes. For example, run "systemctl list-jobs" to
+see what's currently being run, or "systemctl" to find units which are not in
+the expected state (e. g. "failed" for boot or still "active" during shutdown),
+and then get more detailed information with "systemctl status -l foo.service"
+to get a service "foo"'s status and recent logging.
+
+In situations where the debug shell is not available, you can generate a
+/shutdown-log.txt file instead:
+1. Boot with these kernel command line options:
+    systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
+2. Save the following script as /lib/systemd/system-shutdown/debug.sh and make it executable:
+    #!/bin/sh
+    mount -o remount,rw /
+    dmesg > /shutdown-log.txt
+    mount -o remount,ro /
+3. Reboot
+
+Enable and use networkd
+=======================
+networkd is a small and lean service to configure network interfaces, designed
+mostly for server use cases in a world with hotplugged and virtualized
+networking. Its configuration is similar in spirit and abstraction level to
+ifupdown, but you don't need any extra packages to configure bridges, bonds,
+vlan etc. It is not very suitable for managing WLANs yet; NetworkManager is
+still much more appropriate for such Desktop use cases.
+
+networkd is not enabled by default; run
+
+  systemctl enable systemd-networkd
+
+if you want to use it. After that you need to create some *.network
+configuration files. In the simplest case you just want to run DHCP on all
+available Ethernet interfaces:
+
+--- /etc/systemd/network/all-eth.network ---
+[Match]
+Name=e*
+[Network]
+DHCP=yes
+
+This will match on both the kernel "ethN" as well as the predictable interface
+names "en*". Please see man systemd.network(5) for all available configuration
+options and examples.
+
+You need to make sure that interfaces handled by networkd are not handled by
+ifupdown (/etc/network/interfaces) and NetworkManager.
+
+Note that interfaces brought up/down will *not* run hooks in
+/etc/network/if-*.d/.
+
+It is recommended to use networkd together with systemd-resolved(8) to
+dynamically manage /etc/resolv.conf:
+
+  systemctl enable systemd-resolved
+  ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
+
+Debian's networkd has been modified to also work with the resolvconf package.
+
+KillUserProcesses behavior in Debian
+====================================
+
+If KillUserProcesses=yes is configured in logind.conf(5), the session scope
+will be terminated when the user logs out of that session.
+
+See logind.conf(5):
+
+| Note that setting KillUserProcesses=yes will break tools like screen(1) and
+| tmux(1), unless they are moved out of the session scope.
+
+The default for KillUserProcesses in /etc/systemd/logind.conf is set
+to "yes" in upstream systemd, though Debian defaults to "no" (see #825394).