Attachment 633641 Details for Bug 829233 – a better set of commits to address systemd

[patch] a better set of commits to address systemd

systemd-revised-patch.tar (text/plain), 220.00 KB, created by Pete Travis on 2012-10-26 05:38:58 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Pete Travis

Created: 2012-10-26 05:38:58 UTC

Size: 220.00 KB

patch

obsolete

>0001-mentioning-the-initramfs.patch0000664000175000017500000000161112042420374016047 0ustar  petepeteFrom 0150f6cdbbe630969cd65ccbd965dbdafd1e67e5 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Fri, 27 Jul 2012 00:14:02 -0600
>Subject: [PATCH 01/17] mentioning the initramfs
>
>---
> en-US/Boot_Init_Shutdown.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 5713bee..aff5786 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -45,7 +45,7 @@
> 			</listitem>
> 			 <listitem>
> 				<para>
>-					The boot loader loads the kernel into memory, which in turn loads any necessary modules and mounts the root partition read-only.
>+					The boot loader loads the kernel and a small, read-only filesystem into memory. This filesystem, or initramfs, contains all the tools required for the kernel to continue the boot process.
> 				</para>
> 
> 			</listitem>
>-- 
>1.7.11.7
>
>0002-gave-systemd-some-credit-in-the-boot-overview.patch0000664000175000017500000000222312042420374021741 0ustar  petepeteFrom 3d38ae10435f6a8b8f62958868250072cdb84638 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Fri, 27 Jul 2012 00:46:39 -0600
>Subject: [PATCH 02/17] gave systemd some credit in the boot overview
>
>---
> en-US/Boot_Init_Shutdown.xml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index aff5786..61da87a 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -51,13 +51,13 @@
> 			</listitem>
> 			 <listitem>
> 				<para>
>-					The kernel transfers control of the boot process to the <command>/sbin/init</command> program.
>+					The kernel transfers control of the boot process to the system daemon, <command>systemd</command>.
> 				</para>
> 
> 			</listitem>
> 			 <listitem>
> 				<para>
>-					The <command>/sbin/init</command> program loads all services and user-space tools, and mounts all partitions listed in <filename>/etc/fstab</filename>.
>+					<command>systemd</command> loads needed services and user-space tools, and mounts  filesystems listed in <filename>/etc/fstab</filename>.
> 				</para>
> 
> 			</listitem>
>-- 
>1.7.11.7
>
>0003-Removed-admonition-regarding-grub-s-limited-filesyst.patch0000664000175000017500000000346112042420374023321 0ustar  petepeteFrom 613e5a77effced95bb761f282c00bc82f4ec3667 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Fri, 27 Jul 2012 00:56:34 -0600
>Subject: [PATCH 03/17] Removed admonition regarding grub's limited filesystem
> support, as all options mentioned are now supported
> by grub2
>
>---
> en-US/Boot_Init_Shutdown.xml | 7 -------
> 1 file changed, 7 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 61da87a..8173b20 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -190,13 +190,6 @@
> 					</para>
> 				</footnote> partitions and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
> 				</para>
>-				<important>
>-					<title>Important â Supported file systems</title>
>-					<para>
>-						The <application>GRUB</application> bootloader in Fedora&nbsp;&PRODVER; supports ext2, ext3, and ext4 file systems. It does not support other file systems such as VFAT, Btrfs or XFS. Furthermore, <application>GRUB</application> does not support LVM.
>-					</para>
>-
>-				</important>
> 				<para>
> 					Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. If no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
> 				</para>
>-- 
>1.7.11.7
>
>0004-added-a-refererence-for-kernel-parameters.patch0000664000175000017500000000437712042420374021114 0ustar  petepeteFrom 62456bfb2de9b98fc072fbcb235beff3e21ac765 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Sat, 28 Jul 2012 19:18:26 -0600
>Subject: [PATCH 04/17] added a refererence for kernel parameters
>
>---
> en-US/Boot_Init_Shutdown.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 8173b20..a66323b 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -197,7 +197,7 @@
> 					Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the <filename>/boot/</filename> directory. The kernel binary is named using the following format &mdash; <filename>/boot/vmlinuz-<replaceable>&lt;kernel-version&gt;</replaceable></filename> file (where <filename><replaceable>&lt;kernel-version&gt;</replaceable></filename> corresponds to the kernel version specified in the boot loader's settings).
> 				</para>
> 				<para>
>-					For instructions on using the boot loader to supply command line arguments to the kernel, refer to <xref linkend="ch-grub" />. For information on changing the runlevel at the boot loader prompt, refer <xref linkend="s1-grub-runlevels" />.
>+					The bootloader is also used to pass arguments to the kernel it loads.  This allows the system to operate with a specified root filesystem, enable or disable kernel modules and system features, or configure booting to a specific runlevel. For instructions on using the boot loader to supply command line arguments to the kernel, refer to <xref linkend="ch-grub" />. Specific kernel parameters are described in <filename>/usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt</filename>, which is provided by the <package>kernel-doc</package> package. For information on changing the runlevel at the boot loader prompt, refer <xref linkend="s1-grub-runlevels" />.
> 				</para>
> 				<para>
> 					The boot loader then places one or more appropriate <filename>initramfs</filename> images into memory. The <filename>initramfs</filename> is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 or ext4 file system.
>-- 
>1.7.11.7
>
>0005-we-might-mention-there-are-alternative-bootloaders-w.patch0000664000175000017500000000251612042420374023276 0ustar  petepeteFrom 7e978da0690f1e8adde104231df56338c22ab59b Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Sat, 28 Jul 2012 19:39:07 -0600
>Subject: [PATCH 05/17] we might mention there are alternative bootloaders
> when we explain what bootloaders do, but we're only
> going to support the one we ship.
>
>---
> en-US/Boot_Init_Shutdown.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index a66323b..e30bced 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -217,7 +217,7 @@
> 					Once the kernel loads and hands off the boot process to the <command>init</command> command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
> 				</para>
> 				<para>
>-					For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader.
>+					For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside of the scope of this document.
> 				</para>
> 			</section>
> 		</section>
>-- 
>1.7.11.7
>
>0006-added-an-intro-to-systemd-and-described-unit-types.patch0000664000175000017500000003056712042420374022646 0ustar  petepeteFrom edea3a5a8ac6123b7906619cbe95bb376c58e84a Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Sun, 29 Jul 2012 16:50:54 -0600
>Subject: [PATCH 06/17] added an intro to systemd, and described unit types.
>
>---
> en-US/Boot_Init_Shutdown.xml | 146 +++++++++++++++++++++++++++++++++----------
> 1 file changed, 114 insertions(+), 32 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index e30bced..e4734fe 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -185,10 +185,14 @@
> 					The system loads GRUB into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI.
> 				</para>
> 				<para>
>-					GRUB has the advantage of being able to read ext2, ext3, and ext4 <footnote> <para>
>-						GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.
>-					</para>
>-				</footnote> partitions and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
>+					GRUB has the advantage of being able to read ext2, ext3, and ext4 as well as virtual devices such as LVM.
>+				</para>
>+				<footnote> <para>
>+				  GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.
>+				</para>
>+				</footnote>
>+<para>
>+ GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
> 				</para>
> 				<para>
> 					Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. If no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
>@@ -217,19 +221,20 @@
> 					Once the kernel loads and hands off the boot process to the <command>init</command> command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
> 				</para>
> 				<para>
>-					For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside of the scope of this document.
>+					For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside the scope of this document.
> 				</para>
> 			</section>
> 		</section>
> 		
> 		 <section id="s2-boot-init-shutdown-kernel">
> 			<title>The Kernel</title>
>+
> 			 <indexterm significance="normal">
> 				<primary>boot process</primary>
> 				 <secondary>stages of</secondary>
> 				 <tertiary>kernel</tertiary>
>-
> 			</indexterm>
>+
> 			 <indexterm significance="normal">
> 				<primary>kernel</primary>
> 				 <secondary>role in boot process</secondary>
>@@ -245,35 +250,112 @@
> 				At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
> 			</para>
> 			 <para>
>-				To set up the user environment, the kernel executes the <command>/sbin/init</command> program.
>+				To set up the user environment, the kernel executes the system daemon, <command>systemd</command>.
> 			</para>
> 
> 		</section>
>-		
>-		 <section id="s2-boot-init-shutdown-init">
>-			<title>The <command>/sbin/init</command> Program</title>
>-			 <indexterm significance="normal">
>-				<primary><command>init</command> command</primary>
>-				 <secondary>role in boot process</secondary>
>-				 <seealso>boot process</seealso>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary><command>init</command> command</primary>
>-				 <seealso>boot process</seealso>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary>boot process</primary>
>-				 <secondary>stages of</secondary>
>-				 <tertiary><command>/sbin/init</command> command</tertiary>
>-
>-			</indexterm>
>-			 <para>
>-				The <command>/sbin/init</command> program (also called <command>init</command>) coordinates the rest of the boot process and configures the environment for the user.
>+		<section id="s2-boot-init-shutdown-systemd">
>+		  <title>Booting with <command>systemd</command></title>
>+
>+		  <indexterm significance="preferred">
>+		    <primary><command>systemd</command></primary>
>+		    <secondary>role in boot process</secondary>
>+		  </indexterm>
>+
>+		  <indexterm significance="normal">
>+		    <primary>boot process</primary>
>+		    <secondary>stages of</secondary>
>+		  </indexterm>
>+
>+		  <para>
>+		    <command>systemd</command> is the first process started by the kernel. It replaces the venerable <command>SysVinit</command> program (also called <command>init</command>) and the newer <command>Upstart</command> init system. <command>systemd</command> coordinates the rest of the boot process and configures the environment for the user.
>+		  </para>
>+
>+		    
>+		    <itemizedlist>
>+		      <listitem><para>
>+			A socket is created for each daemon that will be launched. The sockets allow daemons to communicate with each other and userspace programs. Because the sockets are abstracted from the processes that use them, interdependent services do not have to wait for each other to come up before sending messages to the socket.
>+		      </para></listitem>
>+		      
>+		      <indexterm significance="normal">
>+			<primary>cgroups</primary>
>+			<secondary>use by <command>systemd</command></secondary>
>+		      </indexterm>
>+
>+		      <listitem><para>
>+			New process started by <command>systemd</command> are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets or by a <xref linkend=''>messaging bus</xref>.
>+		      </para></listitem>
>+		      
>+		      <indexterm significance="normal">
>+			<primary><command>systemd</command></primary>
>+			<secondary>units</secondary>
>+		      </indexterm>
>+			
>+			<para>
>+			  Functions administered by <command>systemd</command> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
>+Let's look at the different types of units:
> 			</para>
>-			 <para>
>-				When the <command>init</command> command starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the <filename>/etc/rc.d/rc.sysinit</filename> script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization. For example, most systems use a clock, so <filename>rc.sysinit</filename> reads the <filename>/etc/sysconfig/clock</filename> configuration file to initialize the hardware clock. Another example is if there are special serial port processes which must be initialized, <filename>rc.sysinit</filename> executes the <filename>/etc/rc.serial</filename> file.
>+			<segmentedlist>
>+			  <segtitle><function>unit</function> type</segtitle>
>+			  <segtitle>Role</segtitle>
>+			  
>+			  <seglistitem>
>+			    <seg><function>socket</function></seg>
>+			    <seg>
>+			      These provide an endpoint for interprocesses communication. Messages can be transported through files, or network or unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
>+			    </seg>
>+			  </seglistitem>
>+
>+
>+			  <seglistitem>
>+			    <seg><function>service</function></seg>
>+			    <seg>
>+			      These are traditional daemons. <function>Service</function> <function>units</function> are described in simple configuration files that define the type, execution, and envoronment of the program, as well as information regarding how <command>systemd</command> should monitor it.
>+			    </seg>
>+			  </seglistitem>
>+			    
>+			  <seglistitem>
>+			    <seg><function>device</function></seg>
>+			    <seg>
>+			      These are automatically created for all devices discovered by the kernel. These <function>units</function> are provided for services that are dependent on devices, or for virtual devices that are dependent on services, as with a network block device.
>+			    </seg>
>+			  </seglistitem>
>+			  
>+			  <seglistitem>
>+			    <seg><function>mount</function></seg>
>+			    <seg>
>+			      These <function>units</function> allow <command>systemd</command>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
>+			    </seg>
>+			  </seglistitem>
>+
>+			  <seglistitem>
>+			    <seg><function>automount</function></seg>
>+			    <seg>
>+			      These <function>units</function> facilitate dynamic mounting of filesystems when their mountpoint is accessed. They are always paired with a <function>mount</function> <function>unit</function>.
>+			    </seg>
>+			  </seglistitem>
>+
>+			  <seglistitem>
>+			    <seg><function>target</function></seg>
>+			    <seg>
>+			      These are logical groupings of <function>units</function> that are required for userspace functionality. Some are large, such as <filename>multi-user.target</filename> that defines a full graphical user environment, or more topical, such as <filename>bluetooth.target</filename> that provides the services a user expects to be available when using bluetooth devices.
>+			    </seg>
>+			  </seglistitem>
>+
>+			  <seglistitem>
>+			    <seg><function>snapshot</function></seg>
>+			    <seg><function>snapshots</function> allow the user to save the state of all <function>units</function> with the command <command>systemctl snapshot</command> and return to that state with <command>systemctl isolate</command>. This is useful for temporary adjustments that don't merit reconfiguration of a target.
>+			    </seg>
>+			  </seglistitem>
>+			</segmentedlist>
>+
>+
>+
>+
>+		      </itemizedlist>
>+
>+<para>
>+		    When <command>systemd</command> starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the <filename>/etc/rc.d/rc.sysinit</filename> script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization. For example, most systems use a clock, so <filename>rc.sysinit</filename> reads the <filename>/etc/sysconfig/clock</filename> configuration file to initialize the hardware clock. Another example is if there are special serial port processes which must be initialized, <filename>rc.sysinit</filename> executes the <filename>/etc/rc.serial</filename> file.
> 			</para>
> 			 <para>
> 				The <command>init</command> command then processes the jobs in the <filename>/etc/event.d</filename> directory, which describe how the system should be set up in each <firstterm>SysV init runlevel</firstterm>. Runlevels are a state, or <firstterm>mode</firstterm>, defined by the services listed in the SysV <filename>/etc/rc.d/rc<replaceable>&lt;x&gt;</replaceable>.d/</filename> directory, where <replaceable>&lt;x&gt;</replaceable> is the number of the runlevel. For more information on SysV init runlevels, refer to <xref linkend="s1-boot-init-shutdown-sysv" />.
>@@ -423,7 +505,7 @@ S99local -&gt; ../rc.local
> 				Once finished, the system operates on runlevel 5 and displays a login screen.
> 			</para>
> 
>-		</section>
>+		      </section>
> 		
> 		 <section id="s2-boot-init-shutdown-jobs">
> 			<title>Job definitions</title>
>-- 
>1.7.11.7
>
>0007-correcting-some-tags.patch0000664000175000017500000003354012042420374015200 0ustar  petepeteFrom 2af34cacad157ccb0d1fda82a5f75de980bc4641 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Mon, 10 Sep 2012 22:39:04 -0600
>Subject: [PATCH 07/17] correcting some tags
>
>---
> en-US/Boot_Init_Shutdown.xml | 132 +++++++++++++++++++++++++------------------
> 1 file changed, 76 insertions(+), 56 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index e4734fe..0f6e868 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -51,13 +51,13 @@
> 			</listitem>
> 			 <listitem>
> 				<para>
>-					The kernel transfers control of the boot process to the system daemon, <command>systemd</command>.
>+					The kernel transfers control of the boot process to the system daemon, <application>systemd</application>.
> 				</para>
> 
> 			</listitem>
> 			 <listitem>
> 				<para>
>-					<command>systemd</command> loads needed services and user-space tools, and mounts  filesystems listed in <filename>/etc/fstab</filename>.
>+					<application>systemd</application> loads needed services and user-space tools, and mounts  filesystems listed in <filename>/etc/fstab</filename>.
> 				</para>
> 
> 			</listitem>
>@@ -187,10 +187,11 @@
> 				<para>
> 					GRUB has the advantage of being able to read ext2, ext3, and ext4 as well as virtual devices such as LVM.
> 				</para>
>-				<footnote> <para>
>-				  GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.
>+				
> <para>
>  GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
> 				</para>
>@@ -250,15 +251,15 @@
> 				At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
> 			</para>
> 			 <para>
>-				To set up the user environment, the kernel executes the system daemon, <command>systemd</command>.
>+				To set up the user environment, the kernel executes the system daemon, <application>systemd</application>.
> 			</para>
> 
> 		</section>
> 		<section id="s2-boot-init-shutdown-systemd">
>-		  <title>Booting with <command>systemd</command></title>
>+		  <title>Booting with <application>systemd</application></title>
> 
> 		  <indexterm significance="preferred">
>-		    <primary><command>systemd</command></primary>
>+		    <primary><application>systemd</application></primary>
> 		    <secondary>role in boot process</secondary>
> 		  </indexterm>
> 
>@@ -268,33 +269,40 @@
> 		  </indexterm>
> 
> 		  <para>
>-		    <command>systemd</command> is the first process started by the kernel. It replaces the venerable <command>SysVinit</command> program (also called <command>init</command>) and the newer <command>Upstart</command> init system. <command>systemd</command> coordinates the rest of the boot process and configures the environment for the user.
>+		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <command>SysVinit</command> program (also called <command>init</command>) and the newer <command>Upstart</command> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
> 		  </para>
> 
>-		    
>-		    <itemizedlist>
>-		      <listitem><para>
>+		  <indexterm significance="normal">
>+		       <primary>cgroups</primary>
>+			<secondary>use by <application>systemd</application></secondary>
>+		     </indexterm>
>+		     
>+
>+		     <itemizedlist>
>+		       <title> The Boot Process </title>
>+		       <listitem><para>
> 			A socket is created for each daemon that will be launched. The sockets allow daemons to communicate with each other and userspace programs. Because the sockets are abstracted from the processes that use them, interdependent services do not have to wait for each other to come up before sending messages to the socket.
>+		       </para></listitem>		       
>+		   
>+		       <listitem><para>
>+			New process started by <application>systemd</application> are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
> 		      </para></listitem>
>-		      
>-		      <indexterm significance="normal">
>-			<primary>cgroups</primary>
>-			<secondary>use by <command>systemd</command></secondary>
>-		      </indexterm>
>+		    </itemizedlist>
>+		    
>+		  </section>
> 
>-		      <listitem><para>
>-			New process started by <command>systemd</command> are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets or by a <xref linkend=''>messaging bus</xref>.
>-		      </para></listitem>
>-		      
>+		  <section id="s2-boot-init-shutdown-systemd-units">
>+		    <title><application>systemd</application> <function>units</function></title>     
> 		      <indexterm significance="normal">
>-			<primary><command>systemd</command></primary>
>+			<primary><application>systemd</application></primary>
> 			<secondary>units</secondary>
> 		      </indexterm>
> 			
> 			<para>
>-			  Functions administered by <command>systemd</command> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
>+			  Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
> Let's look at the different types of units:
> 			</para>
>+		    
> 			<segmentedlist>
> 			  <segtitle><function>unit</function> type</segtitle>
> 			  <segtitle>Role</segtitle>
>@@ -310,7 +318,7 @@ Let's look at the different types of units:
> 			  <seglistitem>
> 			    <seg><function>service</function></seg>
> 			    <seg>
>-			      These are traditional daemons. <function>Service</function> <function>units</function> are described in simple configuration files that define the type, execution, and envoronment of the program, as well as information regarding how <command>systemd</command> should monitor it.
>+			      These are traditional daemons. <function>Service</function> <function>units</function> are described in simple configuration files that define the type, execution, and envoronment of the program, as well as information regarding how <application>systemd</application> should monitor it.
> 			    </seg>
> 			  </seglistitem>
> 			    
>@@ -324,7 +332,7 @@ Let's look at the different types of units:
> 			  <seglistitem>
> 			    <seg><function>mount</function></seg>
> 			    <seg>
>-			      These <function>units</function> allow <command>systemd</command>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
>+			      These <function>units</function> allow <application>systemd</application>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
> 			    </seg>
> 			  </seglistitem>
> 
>@@ -349,13 +357,9 @@ Let's look at the different types of units:
> 			  </seglistitem>
> 			</segmentedlist>
> 
>-
>-
>-
>-		      </itemizedlist>
>-
>+		     
> <para>
>-		    When <command>systemd</command> starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the <filename>/etc/rc.d/rc.sysinit</filename> script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization. For example, most systems use a clock, so <filename>rc.sysinit</filename> reads the <filename>/etc/sysconfig/clock</filename> configuration file to initialize the hardware clock. Another example is if there are special serial port processes which must be initialized, <filename>rc.sysinit</filename> executes the <filename>/etc/rc.serial</filename> file.
>+		    When <application>systemd</application> starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the <filename>/etc/rc.d/rc.sysinit</filename> script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization. For example, most systems use a clock, so <filename>rc.sysinit</filename> reads the <filename>/etc/sysconfig/clock</filename> configuration file to initialize the hardware clock. Another example is if there are special serial port processes which must be initialized, <filename>rc.sysinit</filename> executes the <filename>/etc/rc.serial</filename> file.
> 			</para>
> 			 <para>
> 				The <command>init</command> command then processes the jobs in the <filename>/etc/event.d</filename> directory, which describe how the system should be set up in each <firstterm>SysV init runlevel</firstterm>. Runlevels are a state, or <firstterm>mode</firstterm>, defined by the services listed in the SysV <filename>/etc/rc.d/rc<replaceable>&lt;x&gt;</replaceable>.d/</filename> directory, where <replaceable>&lt;x&gt;</replaceable> is the number of the runlevel. For more information on SysV init runlevels, refer to <xref linkend="s1-boot-init-shutdown-sysv" />.
>@@ -578,34 +582,48 @@ exec /sbin/mingetty tty2
> 
> 	</section>
> 	
>-	 <section id="s1-boot-init-shutdown-sysv">
>-		<title>SysV Init Runlevels</title>
>+	 <section id="s1-boot-init-shutdown-targets">
>+		<title>systemd targets</title>
> 		 <indexterm significance="normal">
>-			<primary>SysV init</primary>
>-			 <see><command>init</command> command</see>
>-
>-		</indexterm>
>-		 <indexterm significance="normal">
>-			<primary><command>init</command> command</primary>
>-			 <secondary>runlevels</secondary>
>-			 <tertiary>directories for</tertiary>
>-
>-		</indexterm>
>+			<primary>systemd</primary>
>+			 <secondary><function>targets</function></secondary>
>+		 </indexterm>
> 		 <indexterm significance="normal">
>-			<primary><command>init</command> command</primary>
>-			 <secondary>SysV init</secondary>
>-			 <tertiary>definition of</tertiary>
>-
>-		</indexterm>
>+		   <primary>runlevels</primary>
>+		 </indexterm>
>+		 
> 		 <indexterm significance="normal">
>-			<primary><command>init</command> command</primary>
>-			 <secondary>configuration files</secondary>
>-			 <tertiary><filename>/etc/inittab</filename> </tertiary>
>-
>-		</indexterm>
>+		   <primary><command>init</command> command</primary>
>+		   <secondary>configuration files</secondary>
>+		   <tertiary><filename>/etc/inittab</filename> </tertiary>
>+		 </indexterm>
> 		 <para>
>-			The SysV init runlevel system provides a standard process for controlling which programs <command>init</command> launches or halts when initializing a runlevel. SysV init was chosen because it is easier to use and more flexible than the traditional BSD-style init process.
>-		</para>
>+		   <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble, the use case they address, and examples of targets they might require.
>+		 </para>
>+		 <table>
>+		   <title>Predefined <application>systemd</application> targets</title>
>+		   <tgroup cols="4" align="left" colsep="1" rowsep="1" />
>+		   <colspec colname="runlevel" colnum="1" />
>+		   <colspec colname="target" colnum="2" />
>+		   <colspec colname="usage" colnum="3" />
>+		   <colspec colname="member_units" colnum="4"
>+		   <thead>
>+		     <row>
>+		       <entry>Runlevel</entry>
>+		       <entry>Target</entry>
>+		       <entry>Usage</entry>
>+		       <entry>Units</entry>
>+		     </row>
>+		   </thead>
>+		   <tbody>
>+		     <row>
>+		       <entry>run</entry>
>+		       <entry></entry>
>+							 <entry>
>+								graphical display
>+							</entry>
>+
>+						</row>
> 		 <para>
> 			The configuration files for SysV init are located in the <filename>/etc/rc.d/</filename> directory. Within this directory, are the <filename>rc</filename>, <filename>rc.local</filename>, <filename>rc.sysinit</filename>, and, optionally, the <filename>rc.serial</filename> scripts as well as the following directories:
> 		</para>
>@@ -615,7 +633,9 @@ exec /sbin/mingetty tty2
> 		 <para>
> 			The <filename>init.d/</filename> directory contains the scripts used by the <command>/sbin/init</command> command when controlling services. Each of the numbered directories represent the six runlevels configured by default under Fedora.
> 		</para>
>-		 <section id="s2-init-boot-shutdown-rl">
>+		
>+
>+ <section id="s2-init-boot-shutdown-rl">
> 			<title>Runlevels</title>
> 			 <indexterm significance="normal">
> 				<primary>runlevels</primary>
>-- 
>1.7.11.7
>
>0008-comments-on-filesystems-supported-by-grub.patch0000664000175000017500000000224312042420374021335 0ustar  petepeteFrom 42405f500bfb396bac0e6413a602cb220b9d2c3d Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Mon, 10 Sep 2012 23:03:47 -0600
>Subject: [PATCH 08/17] comments on filesystems supported by grub
>
>---
> en-US/Boot_Init_Shutdown.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 0f6e868..feb883f 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -185,7 +185,7 @@
> 					The system loads GRUB into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI.
> 				</para>
> 				<para>
>-					GRUB has the advantage of being able to read ext2, ext3, and ext4 as well as virtual devices such as LVM.
>+					<application>GRUB</application> version 2 has the advantage of being able to read a variety of open filesystems, as well as virtual devices such as <application>mdadm</application> RAID arrays and <application>LVM</application> .
> 				</para>
> 				
>+			
> <para>
>  GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
> 				</para>
>-- 
>1.7.11.7
>
>0010-added-comments-on-systemd-compatibility-with-legacy-.patch0000664000175000017500000001414712042420374023263 0ustar  petepeteFrom 978851d077d17a4876c85f9f8f5445d6845f5802 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Tue, 11 Sep 2012 00:31:00 -0600
>Subject: [PATCH 10/17] added comments on systemd compatibility with legacy
> init scripts
>
>---
> en-US/Boot_Init_Shutdown.xml | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index dc777bf..f404b1b 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -203,7 +203,7 @@ A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <f
>  GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
> 				</para>
> 				<para>
>-					Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. If no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
>+					Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. Typically, if no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
> 				</para>
> 				<para>
> 					Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the <filename>/boot/</filename> directory. The kernel binary is named using the following format &mdash; <filename>/boot/vmlinuz-<replaceable>&lt;kernel-version&gt;</replaceable></filename> file (where <filename><replaceable>&lt;kernel-version&gt;</replaceable></filename> corresponds to the kernel version specified in the boot loader's settings).
>@@ -276,9 +276,14 @@ A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <f
> 		  </indexterm>
> 
> 		  <para>
>-		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <command>SysVinit</command> program (also called <command>init</command>) and the newer <command>Upstart</command> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
>+		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <application>SysVinit</application> program (also called <application>init</application>) and the newer <application>Upstart</application> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
> 		  </para>
> 
>+		  <para>
>+		    <application>systemd</application> improves on other init systems by offering increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
>+		  </para>
>+
>+
> 		  <indexterm significance="normal">
> 		       <primary>cgroups</primary>
> 			<secondary>use by <application>systemd</application></secondary>
>@@ -365,11 +370,11 @@ Let's look at the different types of units:
> 			</segmentedlist>
> 
> 		     
>-<para>
>-		    When <application>systemd</application> starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the <filename>/etc/rc.d/rc.sysinit</filename> script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization. For example, most systems use a clock, so <filename>rc.sysinit</filename> reads the <filename>/etc/sysconfig/clock</filename> configuration file to initialize the hardware clock. Another example is if there are special serial port processes which must be initialized, <filename>rc.sysinit</filename> executes the <filename>/etc/rc.serial</filename> file.
>+			<para>
>+			  Although <application>systemd</application> <function>units</function> will ultimately be available for all services, it retains support for legacy init scripts. <function>units</function> are dynamically created for these services, with dependencies inferred from LSB headers in the script. There are drawbacks to this method, so it is best to have a native <application>systemd</application> <function>unit</function> file.
> 			</para>
> 			 <para>
>-				The <command>init</command> command then processes the jobs in the <filename>/etc/event.d</filename> directory, which describe how the system should be set up in each <firstterm>SysV init runlevel</firstterm>. Runlevels are a state, or <firstterm>mode</firstterm>, defined by the services listed in the SysV <filename>/etc/rc.d/rc<replaceable>&lt;x&gt;</replaceable>.d/</filename> directory, where <replaceable>&lt;x&gt;</replaceable> is the number of the runlevel. For more information on SysV init runlevels, refer to <xref linkend="s1-boot-init-shutdown-sysv" />.
>+			   The function and usage of legacy init systems and their configuration files is outside of the scope of this document.
> 			</para>
> 			 <para>
> 				Next, the <command>init</command> command sets the source function library, <filename>/etc/rc.d/init.d/functions</filename>, for the system, which configures how to start, kill, and determine the PID of a program.
>-- 
>1.7.11.7
>
>0011-purging-out-legacy-init-scripts-info.patch0000664000175000017500000001263312042420374020240 0ustar  petepeteFrom be8359e36e1e71388d297b632e93e420f770a6bd Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Tue, 11 Sep 2012 00:32:13 -0600
>Subject: [PATCH 11/17] purging out legacy init scripts info
>
>---
> en-US/Boot_Init_Shutdown.xml | 104 +------------------------------------------
> 1 file changed, 1 insertion(+), 103 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index f404b1b..ad4c01f 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -376,109 +376,7 @@ Let's look at the different types of units:
> 			 <para>
> 			   The function and usage of legacy init systems and their configuration files is outside of the scope of this document.
> 			</para>
>-			 <para>
>-				Next, the <command>init</command> command sets the source function library, <filename>/etc/rc.d/init.d/functions</filename>, for the system, which configures how to start, kill, and determine the PID of a program.
>-			</para>
>-			 <para>
>-				The <command>init</command> program starts all of the background processes by looking in the appropriate <filename>rc</filename> directory for the runlevel specified as the default in <filename>/etc/inittab</filename>. The <filename>rc</filename> directories are numbered to correspond to the runlevel they represent. For instance, <filename>/etc/rc.d/rc5.d/</filename> is the directory for runlevel 5.
>-			</para>
>-			 <para>
>-				When booting to runlevel 5, the <command>init</command> program looks in the <filename>/etc/rc.d/rc5.d/</filename> directory to determine which processes to start and stop.
>-			</para>
>-			 <para>
>-				Below is an example listing of the <filename>/etc/rc.d/rc5.d/</filename> directory:
>-			</para>
>-			
>-<screen>
>-K05innd -&gt; ../init.d/innd 
>-K05saslauthd -&gt; ../init.d/saslauthd 
>-K10dc_server -&gt; ../init.d/dc_server 
>-K10psacct -&gt; ../init.d/psacct 
>-K10radiusd -&gt; ../init.d/radiusd 
>-K12dc_client -&gt; ../init.d/dc_client 
>-K12FreeWnn -&gt; ../init.d/FreeWnn 
>-K12mailman -&gt; ../init.d/mailman 
>-K12mysqld -&gt; ../init.d/mysqld 
>-K15httpd -&gt; ../init.d/httpd 
>-K20netdump-server -&gt; ../init.d/netdump-server 
>-K20rstatd -&gt; ../init.d/rstatd 
>-K20rusersd -&gt; ../init.d/rusersd 
>-K20rwhod -&gt; ../init.d/rwhod 
>-K24irda -&gt; ../init.d/irda 
>-K25squid -&gt; ../init.d/squid 
>-K28amd -&gt; ../init.d/amd 
>-K30spamassassin -&gt; ../init.d/spamassassin 
>-K34dhcrelay -&gt; ../init.d/dhcrelay 
>-K34yppasswdd -&gt; ../init.d/yppasswdd 
>-K35dhcpd -&gt; ../init.d/dhcpd 
>-K35smb -&gt; ../init.d/smb 
>-K35vncserver -&gt; ../init.d/vncserver 
>-K36lisa -&gt; ../init.d/lisa 
>-K45arpwatch -&gt; ../init.d/arpwatch 
>-K45named -&gt; ../init.d/named 
>-K46radvd -&gt; ../init.d/radvd 
>-K50netdump -&gt; ../init.d/netdump 
>-K50snmpd -&gt; ../init.d/snmpd 
>-K50snmptrapd -&gt; ../init.d/snmptrapd 
>-K50tux -&gt; ../init.d/tux 
>-K50vsftpd -&gt; ../init.d/vsftpd 
>-K54dovecot -&gt; ../init.d/dovecot 
>-K61ldap -&gt; ../init.d/ldap 
>-K65kadmin -&gt; ../init.d/kadmin 
>-K65kprop -&gt; ../init.d/kprop 
>-K65krb524 -&gt; ../init.d/krb524 
>-K65krb5kdc -&gt; ../init.d/krb5kdc 
>-K70aep1000 -&gt; ../init.d/aep1000 
>-K70bcm5820 -&gt; ../init.d/bcm5820 
>-K74ypserv -&gt; ../init.d/ypserv 
>-K74ypxfrd -&gt; ../init.d/ypxfrd 
>-K85mdmpd -&gt; ../init.d/mdmpd 
>-K89netplugd -&gt; ../init.d/netplugd 
>-K99microcode_ctl -&gt; ../init.d/microcode_ctl 
>-S04readahead_early -&gt; ../init.d/readahead_early 
>-S05kudzu -&gt; ../init.d/kudzu 
>-S06cpuspeed -&gt; ../init.d/cpuspeed 
>-S08ip6tables -&gt; ../init.d/ip6tables 
>-S08iptables -&gt; ../init.d/iptables 
>-S09isdn -&gt; ../init.d/isdn 
>-S10network -&gt; ../init.d/network 
>-S12syslog -&gt; ../init.d/syslog 
>-S13irqbalance -&gt; ../init.d/irqbalance 
>-S13portmap -&gt; ../init.d/portmap 
>-S15mdmonitor -&gt; ../init.d/mdmonitor 
>-S15zebra -&gt; ../init.d/zebra 
>-S16bgpd -&gt; ../init.d/bgpd 
>-S16ospf6d -&gt; ../init.d/ospf6d 
>-S16ospfd -&gt; ../init.d/ospfd 
>-S16ripd -&gt; ../init.d/ripd 
>-S16ripngd -&gt; ../init.d/ripngd 
>-S20random -&gt; ../init.d/random 
>-S24pcmcia -&gt; ../init.d/pcmcia 
>-S25netfs -&gt; ../init.d/netfs 
>-S26apmd -&gt; ../init.d/apmd 
>-S27ypbind -&gt; ../init.d/ypbind 
>-S28autofs -&gt; ../init.d/autofs 
>-S40smartd -&gt; ../init.d/smartd 
>-S44acpid -&gt; ../init.d/acpid 
>-S54hpoj -&gt; ../init.d/hpoj 
>-S55cups -&gt; ../init.d/cups 
>-S55sshd -&gt; ../init.d/sshd 
>-S56rawdevices -&gt; ../init.d/rawdevices 
>-S56xinetd -&gt; ../init.d/xinetd 
>-S58ntpd -&gt; ../init.d/ntpd 
>-S75postgresql -&gt; ../init.d/postgresql 
>-S80sendmail -&gt; ../init.d/sendmail 
>-S85gpm -&gt; ../init.d/gpm 
>-S87iiim -&gt; ../init.d/iiim 
>-S90canna -&gt; ../init.d/canna 
>-S90crond -&gt; ../init.d/crond 
>-S90xfs -&gt; ../init.d/xfs 
>-S95atd -&gt; ../init.d/atd 
>-S96readahead -&gt; ../init.d/readahead 
>-S97messagebus -&gt; ../init.d/messagebus 
>-S97rhnsd -&gt; ../init.d/rhnsd 
>-S99local -&gt; ../rc.local
>-</screen>
>+			 
> 			 <para>
> 				As illustrated in this listing, none of the scripts that actually start and stop the services are located in the <filename>/etc/rc.d/rc5.d/</filename> directory. Rather, all of the files in <filename>/etc/rc.d/rc5.d/</filename> are <firstterm>symbolic links</firstterm> pointing to scripts located in the <filename>/etc/rc.d/init.d/</filename> directory. Symbolic links are used in each of the <filename>rc</filename> directories so that the runlevels can be reconfigured by creating, modifying, and deleting the symbolic links without affecting the actual scripts they reference.
> 			</para>
>-- 
>1.7.11.7
>
>0012-tag-cleanup.patch0000664000175000017500000014312712042420374013343 0ustar  petepeteFrom a75ec7098cdc166d49b1d7d9db32e8d9f0a7ad61 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Sun, 16 Sep 2012 15:47:28 -0600
>Subject: [PATCH 12/17] tag cleanup
>
>---
> en-US/Boot_Init_Shutdown.xml | 771 ++++++++++++++-----------------------------
> 1 file changed, 247 insertions(+), 524 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index ad4c01f..871657e 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -108,307 +108,269 @@
> 		</para>
> 	
> 		<section id="sect-firmware_interface">
>-			<title>The firmware interface</title>
>-			<section id="s2-boot-init-shutdown-bios">
>-				<title>BIOS-based x86 systems</title>
>-				<indexterm significance="normal">
>-					<primary>Basic Input/Output System</primary>
>-					<see>BIOS</see>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>BIOS</primary>
>-					<secondary>definition of</secondary>
>-					<seealso>boot process</seealso>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>Master Boot Record</primary>
>-					<see>MBR</see>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>MBR</primary>
>-					<secondary>definition of</secondary>
>-					<seealso>boot loaders</seealso>
>-				</indexterm>
>-				<indexterm>
>-				  <primary>GUID Partition Table</primary>
>-				  <see>GPT</see>
>-				<indexterm significance="normal">
>-				  <primary>GPT</primary>
>-				  <secondary>definition of</secondary>
>-				</indexterm>
>-				<para>
>-					The <firstterm>Basic Input/Output System</firstterm> (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it.
>-				</para>
>-				<para>
>-					Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks for bootable media in the specified order.
>-				</para>
>-				<para>
>-A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <firstterm>GUID Partition Table</firstterm> (GPT). The <systemitem>MBR</systemitem> is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. The newer <systemitem>GPT</systemitem> serves the same role and allows for more and larger partitions, but is generally used on newer <systemitem>UEFI</systemitem> systems. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.
>-				</para>
>-
>-				<para>
>-					This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (<application>GRUB</application>) and load the first part of it into memory.
>-				</para>
>-			</section>
>-			<section id="s2-boot-init-shutdown-uefi">
>-				<title>UEFI-based x86 systems</title>
>-				<indexterm significance="normal">
>-					<primary>Extensible Firmware Interface shell</primary>
>-					<see>EFI shell</see>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>EFI shell</primary>
>-					<seealso>boot process</seealso>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>boot process</primary>
>-					<secondary>stages of</secondary>
>-					<tertiary>EFI shell</tertiary>
>-				</indexterm>
>-				<para>
>-					The <firstterm>Unified Extensible Firmware Interface</firstterm> (UEFI) is designed, like BIOS, to control the boot process (through <firstterm>boot services</firstterm>) and to provide an interface between system firmware and an operating system (through <firstterm>runtime services</firstterm>). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems. 
>-				</para>
>-				<para>
>-					When an x86 computer equipped with UEFI boots, the interface searches the system storage for a partition labeled with a specific <firstterm>globally unique identifier</firstterm> (GUID) that marks it as the <firstterm>EFI System Partition</firstterm> (ESP). This partition contains applications compiled for the EFI architecture, which might include bootloaders for operating systems and utility software. UEFI systems include an <firstterm>EFI boot manager</firstterm> that can boot the system from a default configuration, or prompt a user to choose an operating system to boot. When a bootloader is selected, manually or automatically, UEFI reads it into memory and yields control of the boot process to it.
>-				</para>
>-			</section>
>-		</section>
>-		
>-		<section id="s2-boot-init-shutdown-loader">
>-			<title>The Boot Loader</title>
>-			<section id="s2-boot-init-shutdown-loader-bios">
>-				<title>The GRUB boot loader for x86 systems</title>
>-				<indexterm significance="normal">
>-					<primary>boot process</primary>
>-					<secondary>stages of</secondary>
>-					<tertiary>boot loader</tertiary>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>GRUB</primary>
>-					<secondary>role in boot process</secondary>
>-				</indexterm>
>-				<indexterm significance="normal">
>-					<primary>GRUB</primary>
>-					<seealso>boot loaders</seealso>
>-				</indexterm>
>-		
>-				<para>
>-					The system loads GRUB into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI.
>-				</para>
>-				<para>
>-					<application>GRUB</application> version 2 has the advantage of being able to read a variety of open filesystems, as well as virtual devices such as <application>mdadm</application> RAID arrays and <application>LVM</application> .
>-				</para>
>-			
>-<para>
>- GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
>-				</para>
>-				<para>
>-					Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. Typically, if no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
>-				</para>
>-				<para>
>-					Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the <filename>/boot/</filename> directory. The kernel binary is named using the following format &mdash; <filename>/boot/vmlinuz-<replaceable>&lt;kernel-version&gt;</replaceable></filename> file (where <filename><replaceable>&lt;kernel-version&gt;</replaceable></filename> corresponds to the kernel version specified in the boot loader's settings).
>-				</para>
>-				<para>
>-					The bootloader is also used to pass arguments to the kernel it loads.  This allows the system to operate with a specified root filesystem, enable or disable kernel modules and system features, or configure booting to a specific runlevel. For instructions on using the boot loader to supply command line arguments to the kernel, refer to <xref linkend="ch-grub" />. Specific kernel parameters are described in <filename>/usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt</filename>, which is provided by the <package>kernel-doc</package> package. For information on changing the runlevel at the boot loader prompt, refer <xref linkend="s1-grub-runlevels" />.
>-				</para>
>-				<para>
>-					The boot loader then places one or more appropriate <filename>initramfs</filename> images into memory. The <filename>initramfs</filename> is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 or ext4 file system.
>-				</para>
>-				<para>
>-					Once the kernel and the <filename>initramfs</filename> image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel.
>-				</para>
>-				<para>
>-					For a more detailed overview of the GRUB boot loader, refer to <xref linkend="ch-grub" />.
>-				</para>
>-			
>-			</section>
>-			
>-			<section id="s3-boot-init-shutdown-other-architectures">
>-				<title>Boot Loaders for Other Architectures</title>
>-				<para>
>-					Once the kernel loads and hands off the boot process to the <command>init</command> command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
>-				</para>
>-				<para>
>-					For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside the scope of this document.
>-				</para>
>-			</section>
>-		</section>
>-		
>-		 <section id="s2-boot-init-shutdown-kernel">
>-			<title>The Kernel</title>
>-
>-			 <indexterm significance="normal">
>-				<primary>boot process</primary>
>-				 <secondary>stages of</secondary>
>-				 <tertiary>kernel</tertiary>
>-			</indexterm>
>-
>-			 <indexterm significance="normal">
>-				<primary>kernel</primary>
>-				 <secondary>role in boot process</secondary>
>-
>-			</indexterm>
>-			 <para>
>-				When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed <filename>initramfs</filename> image(s) in a predetermined location in memory, decompresses it directly to <filename>/sysroot/</filename> via <command>cpio</command>, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID, before completing the <filename>initramfs</filename> processes and freeing up all the memory the disk image once occupied.
>-			</para>
>-			 <para>
>-				The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory.
>-			</para>
>-			 <para>
>-				At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
>-			</para>
>-			 <para>
>-				To set up the user environment, the kernel executes the system daemon, <application>systemd</application>.
>-			</para>
>-
>+		  <title>The firmware interface</title>
>+		  <section id="s2-boot-init-shutdown-bios">
>+		    <title>BIOS-based x86 systems</title>
>+		    <indexterm significance="normal">
>+		      <primary>Basic Input/Output System</primary>
>+		      <see>BIOS</see>
>+		    </indexterm>
>+		    <indexterm significance="normal">
>+		      <primary>BIOS</primary>
>+		      <secondary>definition of</secondary>
>+		      <seealso>boot process</seealso>
>+		    </indexterm>
>+		    <indexterm significance="normal">
>+		      <primary>Master Boot Record</primary>
>+		      <see>MBR</see>
>+		    </indexterm>
>+		    <indexterm significance="normal">
>+		      <primary>MBR</primary>
>+		      <secondary>definition of</secondary>
>+		      <seealso>boot loaders</seealso>
>+		    </indexterm>
>+		    <indexterm>
>+		      <primary>GUID Partition Table</primary>
>+		      <see>GPT</see>
>+		    </indexterm>
>+		    <indexterm significance="normal">
>+		      <primary>GPT</primary>
>+		      <secondary>definition of</secondary>
>+		    </indexterm>
>+		    <para>
>+		      The <firstterm>Basic Input/Output System</firstterm> (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it.
>+		    </para>
>+		    <para>
>+			Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks for bootable media in the specified order.
>+		    </para>
>+		    <para>
>+			A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <firstterm>GUID Partition Table</firstterm> (GPT). The <systemitem>MBR</systemitem> is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. The newer <systemitem>GPT</systemitem> serves the same role and allows for more and larger partitions, but is generally used on newer <systemitem>UEFI</systemitem> systems. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.
>+		    </para>
>+		    <para>
>+			This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (<application>GRUB</application>) and load the first part of it into memory.
>+		    </para>
>+		  </section>
> 		</section>
>-		<section id="s2-boot-init-shutdown-systemd">
>-		  <title>Booting with <application>systemd</application></title>
>-
>-		  <indexterm significance="preferred">
>-		    <primary><application>systemd</application></primary>
>-		    <secondary>role in boot process</secondary>
>+		<section id="s2-boot-init-shutdown-uefi">
>+		  <title>UEFI-based x86 systems</title>
>+		  <indexterm significance="normal">
>+		    <primary>Extensible Firmware Interface shell</primary>
>+		    <see>EFI shell</see>
>+		  </indexterm>
>+		  <indexterm significance="normal">
>+		    <primary>EFI shell</primary>
>+		    <seealso>boot process</seealso>
> 		  </indexterm>
>-
> 		  <indexterm significance="normal">
> 		    <primary>boot process</primary>
> 		    <secondary>stages of</secondary>
>+		    <tertiary>EFI shell</tertiary>
> 		  </indexterm>
>-
> 		  <para>
>-		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <application>SysVinit</application> program (also called <application>init</application>) and the newer <application>Upstart</application> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
>+		    The <firstterm>Unified Extensible Firmware Interface</firstterm> (UEFI) is designed, like BIOS, to control the boot process (through <firstterm>boot services</firstterm>) and to provide an interface between system firmware and an operating system (through <firstterm>runtime services</firstterm>). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems. 
> 		  </para>
>-
> 		  <para>
>-		    <application>systemd</application> improves on other init systems by offering increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
>+		    When an x86 computer equipped with UEFI boots, the interface searches the system storage for a partition labeled with a specific <firstterm>globally unique identifier</firstterm> (GUID) that marks it as the <firstterm>EFI System Partition</firstterm> (ESP). This partition contains applications compiled for the EFI architecture, which might include bootloaders for operating systems and utility software. UEFI systems include an <firstterm>EFI boot manager</firstterm> that can boot the system from a default configuration, or prompt a user to choose an operating system to boot. When a bootloader is selected, manually or automatically, UEFI reads it into memory and yields control of the boot process to it.
> 		  </para>
>-
>-
>+		</section>
>+	      </section>
>+	      <section id="s2-boot-init-shutdown-loader">
>+		<title>The Boot Loader</title>
>+		<section id="s2-boot-init-shutdown-loader-bios">
>+		  <title>The GRUB boot loader for x86 systems</title>
> 		  <indexterm significance="normal">
>-		       <primary>cgroups</primary>
>-			<secondary>use by <application>systemd</application></secondary>
>-		     </indexterm>
>-		     
>-
>-		     <itemizedlist>
>-		       <title> The Boot Process </title>
>-		       <listitem><para>
>+		    <primary>boot process</primary>
>+		    <secondary>stages of</secondary>
>+		    <tertiary>boot loader</tertiary>
>+		  </indexterm>
>+		  <indexterm significance="normal">
>+		    <primary>GRUB</primary>
>+		    <secondary>role in boot process</secondary>
>+		  </indexterm>
>+		  <indexterm significance="normal">
>+		    <primary>GRUB</primary>
>+		    <seealso>boot loaders</seealso>
>+		  </indexterm>
>+		  <para>
>+		    The system loads GRUB into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI.
>+		  </para>
>+		  <para>
>+		    <application>GRUB</application> version 2 has the advantage of being able to read a variety of open filesystems, as well as virtual devices such as <application>mdadm</application> RAID arrays and <application>LVM</application> .
>+		  </para>
>+		  <para>
>+		    GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
>+		  </para>
>+		  <para>
>+		    Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. Typically, if no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
>+		  </para>
>+		  <para>
>+		    Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the <filename>/boot/</filename> directory. The kernel binary is named using the following format &mdash; <filename>/boot/vmlinuz-<replaceable>&lt;kernel-version&gt;</replaceable></filename> file (where <filename><replaceable>&lt;kernel-version&gt;</replaceable></filename> corresponds to the kernel version specified in the boot loader's settings).
>+		  </para>
>+		  <para>
>+		    The bootloader is also used to pass arguments to the kernel it loads.  This allows the system to operate with a specified root filesystem, enable or disable kernel modules and system features, or configure booting to a specific runlevel. For instructions on using the boot loader to supply command line arguments to the kernel, refer to <xref linkend="ch-grub" />. Specific kernel parameters are described in <filename>/usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt</filename>, which is provided by the <package>kernel-doc</package> package. For information on changing the runlevel at the boot loader prompt, refer <xref linkend="s1-grub-runlevels" />.
>+		  </para>
>+		  <para>
>+		    The boot loader then places one or more appropriate <filename>initramfs</filename> images into memory. The <filename>initramfs</filename> is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 or ext4 file system.
>+		  </para>
>+		  <para>
>+		    Once the kernel and the <filename>initramfs</filename> image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel.
>+		  </para>
>+		  <para>
>+		    For a more detailed overview of the GRUB boot loader, refer to <xref linkend="ch-grub" />.
>+		  </para>
>+		</section>
>+		<section id="s3-boot-init-shutdown-other-architectures">
>+		  <title>Boot Loaders for Other Architectures</title>
>+		  <para>
>+		    Once the kernel loads and hands off the boot process to the <command>init</command> command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
>+		  </para>
>+		  <para>
>+		    For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside the scope of this document.
>+		  </para>
>+		</section>
>+	      </section>
>+	      <section id="s2-boot-init-shutdown-kernel">
>+		<title>The Kernel</title>
>+		<indexterm significance="normal">
>+		  <primary>boot process</primary>
>+		  <secondary>stages of</secondary>
>+		  <tertiary>kernel</tertiary>
>+		</indexterm>
>+		<indexterm significance="normal">
>+		  <primary>kernel</primary>
>+		  <secondary>role in boot process</secondary>
>+		</indexterm>
>+		<para>
>+		  When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed <filename>initramfs</filename> image(s) in a predetermined location in memory, decompresses it directly to <filename>/sysroot/</filename> via <command>cpio</command>, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID, before completing the <filename>initramfs</filename> processes and freeing up all the memory the disk image once occupied.
>+		</para>
>+		<para>
>+		  The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory.
>+		</para>
>+		<para>
>+		  At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
>+		</para>
>+		<para>
>+		  To set up the user environment, the kernel executes the system daemon, <application>systemd</application>.
>+		</para>
>+	      </section>
>+	      <section id="s2-boot-init-shutdown-systemd">
>+		<title>Booting with <application>systemd</application></title>
>+		<indexterm significance="preferred">
>+		  <primary><application>systemd</application></primary>
>+		  <secondary>role in boot process</secondary>
>+		</indexterm>
>+		<indexterm significance="normal">
>+		  <primary>boot process</primary>
>+		  <secondary>stages of</secondary>
>+		</indexterm>
>+		<para>
>+		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <application>SysVinit</application> program (also called <application>init</application>) and the newer <application>Upstart</application> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
>+		</para>
>+		<para>
>+		  <application>systemd</application> improves on other init systems by offering increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
>+		</para>
>+		
>+		<indexterm significance="normal">
>+		  <primary>cgroups</primary>
>+		  <secondary>use by <application>systemd</application></secondary>
>+		</indexterm>
>+		
>+		<itemizedlist>
>+		  <title> The Boot Process </title>
>+		  <listitem><para>
> 			A socket is created for each daemon that will be launched. The sockets allow daemons to communicate with each other and userspace programs. Because the sockets are abstracted from the processes that use them, interdependent services do not have to wait for each other to come up before sending messages to the socket.
>-		       </para></listitem>		       
>-		   
>-		       <listitem><para>
>+		  </para></listitem>		       
>+		  
>+		  <listitem><para>
> 			New process started by <application>systemd</application> are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
>-		      </para></listitem>
>-		    </itemizedlist>
>+		  </para></listitem>
>+		</itemizedlist>
> 		    
>-		  </section>
>-
>-		  <section id="s2-boot-init-shutdown-systemd-units">
>-		    <title><application>systemd</application> <function>units</function></title>     
>-		      <indexterm significance="normal">
>-			<primary><application>systemd</application></primary>
>-			<secondary>units</secondary>
>-		      </indexterm>
>-			
>-			<para>
>+	      </section>
>+	      
>+	      <section id="s2-boot-init-shutdown-systemd-units">
>+		<title><application>systemd</application> <function>units</function></title>     
>+		<indexterm significance="normal">
>+		  <primary><application>systemd</application></primary>
>+		  <secondary>units</secondary>
>+		</indexterm>
>+		
>+		<para>
> 			  Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
> Let's look at the different types of units:
>-			</para>
>+		</para>
> 		    
>-			<segmentedlist>
>-			  <segtitle><function>unit</function> type</segtitle>
>-			  <segtitle>Role</segtitle>
>-			  
>-			  <seglistitem>
>-			    <seg><function>socket</function></seg>
>-			    <seg>
>-			      These provide an endpoint for interprocesses communication. Messages can be transported through files, or network or unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
>-			    </seg>
>-			  </seglistitem>
>-
>-
>-			  <seglistitem>
>-			    <seg><function>service</function></seg>
>-			    <seg>
>+		<segmentedlist>
>+		  <segtitle><function>unit</function> type</segtitle>
>+		  <segtitle>Role</segtitle>
>+		  <seglistitem>
>+		    <seg><function>socket</function></seg>
>+		    <seg>
>+		      These provide an endpoint for interprocesses communication. Messages can be transported through files, or network or unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
>+		    </seg>
>+		  </seglistitem>
>+		  
>+		  <seglistitem>
>+		    <seg><function>service</function></seg>
>+		    <seg>
> 			      These are traditional daemons. <function>Service</function> <function>units</function> are described in simple configuration files that define the type, execution, and envoronment of the program, as well as information regarding how <application>systemd</application> should monitor it.
>-			    </seg>
>-			  </seglistitem>
>+		    </seg>
>+		  </seglistitem>
> 			    
>-			  <seglistitem>
>-			    <seg><function>device</function></seg>
>-			    <seg>
>-			      These are automatically created for all devices discovered by the kernel. These <function>units</function> are provided for services that are dependent on devices, or for virtual devices that are dependent on services, as with a network block device.
>-			    </seg>
>-			  </seglistitem>
>-			  
>-			  <seglistitem>
>-			    <seg><function>mount</function></seg>
>-			    <seg>
>-			      These <function>units</function> allow <application>systemd</application>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
>-			    </seg>
>-			  </seglistitem>
>-
>-			  <seglistitem>
>-			    <seg><function>automount</function></seg>
>-			    <seg>
>+		  <seglistitem>
>+		    <seg><function>device</function></seg>
>+		    <seg>
>+		      These are automatically created for all devices discovered by the kernel. These <function>units</function> are provided for services that are dependent on devices, or for virtual devices that are dependent on services, as with a network block device.
>+		    </seg>
>+		  </seglistitem>
>+		  
>+		  <seglistitem>
>+		    <seg><function>mount</function></seg>
>+		    <seg>
>+		      These <function>units</function> allow <application>systemd</application>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
>+		    </seg>
>+		  </seglistitem>
>+
>+		  <seglistitem>
>+		    <seg><function>automount</function></seg>
>+		    <seg>
> 			      These <function>units</function> facilitate dynamic mounting of filesystems when their mountpoint is accessed. They are always paired with a <function>mount</function> <function>unit</function>.
>-			    </seg>
>-			  </seglistitem>
>+		    </seg>
>+		  </seglistitem>
> 
>-			  <seglistitem>
>-			    <seg><function>target</function></seg>
>-			    <seg>
>+		  <seglistitem>
>+		    <seg><function>target</function></seg>
>+		    <seg>
> 			      These are logical groupings of <function>units</function> that are required for userspace functionality. Some are large, such as <filename>multi-user.target</filename> that defines a full graphical user environment, or more topical, such as <filename>bluetooth.target</filename> that provides the services a user expects to be available when using bluetooth devices.
>-			    </seg>
>-			  </seglistitem>
>+		    </seg>
>+		  </seglistitem>
> 
>-			  <seglistitem>
>-			    <seg><function>snapshot</function></seg>
>-			    <seg><function>snapshots</function> allow the user to save the state of all <function>units</function> with the command <command>systemctl snapshot</command> and return to that state with <command>systemctl isolate</command>. This is useful for temporary adjustments that don't merit reconfiguration of a target.
>-			    </seg>
>-			  </seglistitem>
>-			</segmentedlist>
>+		  <seglistitem>
>+		    <seg><function>snapshot</function></seg>
>+		    <seg><function>snapshots</function> allow the user to save the state of all <function>units</function> with the command <command>systemctl snapshot</command> and return to that state with <command>systemctl isolate</command>. This is useful for temporary adjustments that don't merit reconfiguration of a target.
>+		    </seg>
>+		  </seglistitem>
>+		</segmentedlist>
> 
> 		     
>-			<para>
>-			  Although <application>systemd</application> <function>units</function> will ultimately be available for all services, it retains support for legacy init scripts. <function>units</function> are dynamically created for these services, with dependencies inferred from LSB headers in the script. There are drawbacks to this method, so it is best to have a native <application>systemd</application> <function>unit</function> file.
>-			</para>
>-			 <para>
>-			   The function and usage of legacy init systems and their configuration files is outside of the scope of this document.
>-			</para>
>+		<para>
>+		  Although <application>systemd</application> <function>units</function> will ultimately be available for all services, it retains support for legacy init scripts. <function>units</function> are dynamically created for these services, with dependencies inferred from LSB headers in the script. There are drawbacks to this method, so it is best to have a native <application>systemd</application> <function>unit</function> file.
>+		</para>
>+		<para>
>+		  The function and usage of legacy init systems and their configuration files is outside of the scope of this document.
>+		</para>
> 			 
>-			 <para>
>-				As illustrated in this listing, none of the scripts that actually start and stop the services are located in the <filename>/etc/rc.d/rc5.d/</filename> directory. Rather, all of the files in <filename>/etc/rc.d/rc5.d/</filename> are <firstterm>symbolic links</firstterm> pointing to scripts located in the <filename>/etc/rc.d/init.d/</filename> directory. Symbolic links are used in each of the <filename>rc</filename> directories so that the runlevels can be reconfigured by creating, modifying, and deleting the symbolic links without affecting the actual scripts they reference.
>-			</para>
>-			 <para>
>-				The name of each symbolic link begins with either a <computeroutput>K</computeroutput> or an <computeroutput>S</computeroutput>. The <computeroutput>K</computeroutput> links are processes that are killed on that runlevel, while those beginning with an <computeroutput>S</computeroutput> are started.
>-			</para>
>-			 <para>
>-				The <command>init</command> command first stops all of the <computeroutput>K</computeroutput> symbolic links in the directory by issuing the <command>/etc/rc.d/init.d/<replaceable>&lt;command&gt;</replaceable> stop</command> command, where <replaceable>&lt;command&gt;</replaceable> is the process to be killed. It then starts all of the <computeroutput>S</computeroutput> symbolic links by issuing <command>/etc/rc.d/init.d/<replaceable>&lt;command&gt;</replaceable> start</command>.
>-			</para>
>-			 <note>
>-				<title>Note</title>
>-				 <para>
>-					After the system is finished booting, it is possible to log in as root and execute these same scripts to start and stop services. For instance, the command <command>/etc/rc.d/init.d/httpd stop</command> stops the Apache HTTP Server.
>-				</para>
>-
>-			</note>
>-			 <para>
>-				Each of the symbolic links are numbered to dictate start order. The order in which the services are started or stopped can be altered by changing this number. The lower the number, the earlier it is started. Symbolic links with the same number are started alphabetically.
>-			</para>
>-			 <note>
>-				<title>Note</title>
>-				 <para>
>-					One of the last things the <command>init</command> program executes is the <filename>/etc/rc.d/rc.local</filename> file. This file is useful for system customization. Refer to <xref linkend="s1-boot-init-shutdown-run-boot" /> for more information about using the <filename>rc.local</filename> file.
>-				</para>
>-
>-			</note>
>-			 <para>
>+						 
>+			
>+			
>+			
>+
> 
> 	</section>
> 	
>@@ -508,7 +436,8 @@ exec /sbin/mingetty tty2
> 		   <tertiary><filename>/etc/inittab</filename> </tertiary>
> 		 </indexterm>
> 		 <para>
>-		   <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble, the use case they address, and examples of targets they might require.
>+
>+		   <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble and the use case they address.
> 		 </para>
> 		 <table>
> 		   <title>Predefined <application>systemd</application> targets</title>
>@@ -516,7 +445,7 @@ exec /sbin/mingetty tty2
> 		   <colspec colname="runlevel" colnum="1" />
> 		   <colspec colname="target" colnum="2" />
> 		   <colspec colname="usage" colnum="3" />
>-		   <colspec colname="member_units" colnum="4"
>+		   <colspec colname="member_units" colnum="4" />
> 		   <thead>
> 		     <row>
> 		       <entry>Runlevel</entry>
>@@ -527,118 +456,12 @@ exec /sbin/mingetty tty2
> 		   </thead>
> 		   <tbody>
> 		     <row>
>-		       <entry>run</entry>
>-		       <entry></entry>
>-							 <entry>
>-								graphical display
>-							</entry>
>-
>-						</row>
>-		 <para>
>-			The configuration files for SysV init are located in the <filename>/etc/rc.d/</filename> directory. Within this directory, are the <filename>rc</filename>, <filename>rc.local</filename>, <filename>rc.sysinit</filename>, and, optionally, the <filename>rc.serial</filename> scripts as well as the following directories:
>-		</para>
>-		
>-<screen>
>-<computeroutput>init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/</computeroutput></screen>
>-		 <para>
>-			The <filename>init.d/</filename> directory contains the scripts used by the <command>/sbin/init</command> command when controlling services. Each of the numbered directories represent the six runlevels configured by default under Fedora.
>-		</para>
>-		
>-
>- <section id="s2-init-boot-shutdown-rl">
>-			<title>Runlevels</title>
>-			 <indexterm significance="normal">
>-				<primary>runlevels</primary>
>-				 <see><command>init</command> command</see>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary><command>init</command> command</primary>
>-				 <secondary>runlevels accessed by</secondary>
>-
>-			</indexterm>
>-			 <para>
>-				The idea behind SysV init runlevels revolves around the idea that different systems can be used in different ways. For example, a server runs more efficiently without the drag on system resources created by the X Window System. Or there may be times when a system administrator may need to operate the system at a lower runlevel to perform diagnostic tasks, like fixing disk corruption in runlevel 1.
>-			</para>
>-			 <para>
>-				The characteristics of a given runlevel determine which services are halted and started by <command>init</command>. For instance, runlevel 1 (single user mode) halts any network services, while runlevel 3 starts these services. By assigning specific services to be halted or started on a given runlevel, <command>init</command> can quickly change the mode of the machine without the user manually stopping and starting services.
>-			</para>
>-			 <para>
>-				The following runlevels are defined by default under Fedora:
>-			</para>
>-			 <blockquote>
>-				<itemizedlist>
>-					<listitem>
>-						<para>
>-							<command>0</command> &mdash; Halt
>-						</para>
>-
>-					</listitem>
>-					 <listitem>
>-						<para>
>-							<command>1</command> &mdash; Single-user text mode
>-						</para>
>-
>-					</listitem>
>-					 <listitem>
>-						<para>
>-							<command>2</command> &mdash; Not used (user-definable)
>-						</para>
>-
>-					</listitem>
>-					 <listitem>
>-						<para>
>-							<command>3</command> &mdash; Full multi-user text mode
>-						</para>
>-
>-					</listitem>
>-					 <listitem>
>-						<para>
>-							<command>4</command> &mdash; Not used (user-definable)
>-						</para>
>-
>-					</listitem>
>-					 <listitem>
>-						<para>
>-							<command>5</command> &mdash; Full multi-user graphical mode (with an X-based login screen)
>-						</para>
>-
>-					</listitem>
>-					 <listitem>
>-						<para>
>-							<command>6</command> &mdash; Reboot
>-						</para>
>-
>-					</listitem>
>-
>-				</itemizedlist>
>-
>-			</blockquote>
>-			 <para>
>-				In general, users operate Fedora at runlevel 3 or runlevel 5 &mdash; both full multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific needs, since they are not used.
>-			</para>
>-			 <para>
>-				The default runlevel for the system is listed in <filename>/etc/inittab</filename>. To find out the default runlevel for a system, look for the line similar to the following near the bottom of <filename>/etc/inittab</filename>:
>-			</para>
>-			
>-<screen>
>-<computeroutput>id:5:initdefault:</computeroutput></screen>
>-			 <para>
>-				The default runlevel listed in this example is five, as the number after the first colon indicates. To change it, edit <filename>/etc/inittab</filename> as root.
>-			</para>
>-			 <warning>
>-				<title>Warning</title>
>-				 <para>
>-					Be very careful when editing <filename>/etc/inittab</filename>. Simple typos can cause the system to become unbootable. If this happens, either use a boot diskette, enter single-user mode, or enter rescue mode to boot the computer and repair the file.
>-				</para>
>-				 <para>
>-					For more information on single-user and rescue mode, refer to the chapter titled <citetitle>Basic System Recovery</citetitle> in the <citetitle>Fedora Deployment Guide</citetitle>.
>-				</para>
>-
>-			</warning>
>-			 <para>
>-				It is possible to change the default runlevel at boot time by modifying the arguments passed by the boot loader to the kernel. For information on changing the runlevel at boot time, refer to <xref linkend="s1-grub-runlevels" />.
>-			</para>
>+		       <entry>1,single</entry>
>+		       <entry>rescue.target</entry>
>+		       <entry>single user mode, for recovery of critical system components or configuration</entry>
>+         	     </row>
>+		   </tbody>
>+		 </table>
> 
> 		</section>
> 		
>@@ -648,112 +471,12 @@ exec /sbin/mingetty tty2
> 				<primary>runlevels</primary>
> 				 <secondary>configuration of</secondary>
> 				 <seealso>services</seealso>
>+			 </indexterm>
> 
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary><application>Services Configuration Tool</application> </primary>
>-				 <seealso>services</seealso>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary>services</primary>
>-				 <secondary>configuring with <application>Services Configuration Tool</application> </secondary>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary><application>ntsysv</application> </primary>
>-				 <seealso>services</seealso>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary>services</primary>
>-				 <secondary>configuring with <application>ntsysv</application> </secondary>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary>services</primary>
>-				 <secondary>configuring with <command>chkconfig</command> </secondary>
>-
>-			</indexterm>
>-			 <indexterm significance="normal">
>-				<primary><command>chkconfig</command> </primary>
>-				 <seealso>services</seealso>
>-
>-			</indexterm>
>-			 <para>
>-				One of the best ways to configure runlevels is to use an <firstterm>initscript utility</firstterm>. These tools are designed to simplify the task of maintaining files in the SysV init directory hierarchy and relieves system administrators from having to directly manipulate the numerous symbolic links in the subdirectories of <filename>/etc/rc.d/</filename>.
>-			</para>
>-			 <para>
>-				Fedora provides three such utilities:
>-			</para>
>-			 <itemizedlist>
>-				<listitem>
>-					<para>
>-						<command>/sbin/chkconfig</command> &mdash; The <command>/sbin/chkconfig</command> utility is a simple command line tool for maintaining the <filename>/etc/rc.d/init.d/</filename> directory hierarchy.
>-					</para>
>-
>-				</listitem>
>-				 <listitem>
>-					<para>
>-						<application>/usr/sbin/ntsysv</application> &mdash; The ncurses-based <application>/sbin/ntsysv</application> utility provides an interactive text-based interface, which some find easier to use than <command>chkconfig</command>.
>-					</para>
>-
>-				</listitem>
>-				 <listitem>
>-					<para>
>-						<application>Services Configuration Tool</application> &mdash; The graphical <application>Services Configuration Tool</application> (<command>system-config-services</command>) program is a flexible utility for configuring runlevels.
>-					</para>
>-
>-				</listitem>
>-
>-			</itemizedlist>
>-			 <para>
>-				Refer to the chapter titled <citetitle>Controlling Access to Services</citetitle> in the <citetitle>Fedora Deployment Guide</citetitle> for more information regarding these tools.
>-			</para>
>-
>-		</section>
>-		
>-
>-	</section>
>-	
>-	 <section id="s1-boot-init-shutdown-shutdown">
>-		<title>Shutting Down</title>
>-		 <indexterm significance="normal">
>-			<primary>shutdown</primary>
>-			 <seealso>halt</seealso>
>-
>-		</indexterm>
>-		 <indexterm significance="normal">
>-			<primary>halt</primary>
>-			 <seealso>shutdown</seealso>
>-
>-		</indexterm>
>-		 <para>
>-			To shut down Fedora, the root user may issue the <command>/sbin/shutdown</command> command. The <command>shutdown</command> man page has a complete list of options, but the two most common uses are:
>-		</para>
>-		
>-<screen>
>-<command>/sbin/shutdown -h now</command></screen>
>-		 <para>
>-			and
>-		</para>
>-		
>-<screen>
>-<command>/sbin/shutdown -r now</command></screen>
>-		 <para>
>-			After shutting everything down, the <command>-h</command> option halts the machine, and the <command>-r</command> option reboots.
>-		</para>
>-		 <para>
>-			PAM console users can use the <command>reboot</command> and <command>halt</command> commands to shut down the system while in runlevels 1 through 5. For more information about PAM console users, refer to the Fedora Deployment Guide.
>-		</para>
>-		 <para>
>-			If the computer does not power itself down, be careful not to turn off the computer until a message appears indicating that the system is halted.
>-		</para>
>-		 <para>
>-			Failure to wait for this message can mean that not all the hard drive partitions are unmounted, which can lead to file system corruption.
>-		</para>
>+		 </section>
>+		
> 
>-	</section>
>+
> 	
> 
> </appendix>
>-- 
>1.7.11.7
>
>0013-Added-systemd-target-description-minor-changes-in-ot.patch0000664000175000017500000010352312042420374023210 0ustar  petepeteFrom dfec68d3b443c98e08dfde1119c52812f324694c Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Mon, 17 Sep 2012 00:18:24 -0600
>Subject: [PATCH 13/17] Added systemd target description, minor changes in
> other areas.
>
>---
> en-US/Boot_Init_Shutdown.xml | 535 +++++++++++++++++++++++--------------------
> 1 file changed, 292 insertions(+), 243 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 871657e..577b832 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -4,177 +4,177 @@
> %BOOK_ENTITIES;
> ]>
> <appendix id="ch-boot-init-shutdown">
>-	<title>Boot Process, Init, and Shutdown</title>
>-	 <indexterm significance="normal">
>-		<primary>boot process</primary>
>-
>-	</indexterm>
>-	 <para>
>-		An important and powerful aspect of Fedora is the open, user-configurable method it uses for starting the operating system. Users are free to configure many aspects of the boot process, including specifying the programs launched at boot-time. Similarly, system shutdown gracefully terminates processes in an organized and configurable way, although customization of this process is rarely required.
>+  <title>Boot Process, Init, and Shutdown</title>
>+  <indexterm significance="normal">
>+    <primary>boot process</primary>
>+    
>+  </indexterm>
>+  <para>
>+    An important and powerful aspect of Fedora is the open, user-configurable method it uses for starting the operating system. Users are free to configure many aspects of the boot process, including specifying the programs launched at boot-time. Similarly, system shutdown gracefully terminates processes in an organized and configurable way, although customization of this process is rarely required.
>+  </para>
>+  <para>
>+    Understanding how the boot and shutdown processes work not only allows customization, but also makes it easier to troubleshoot problems related to starting or shutting down the system.
>+  </para>
>+  <section id="s1-boot-process-basics">
>+    <title>The Boot Process</title>
>+    <indexterm significance="normal">
>+      <primary>boot process</primary>
>+      <secondary>stages of</secondary>
>+      
>+    </indexterm>
>+    <para>
>+	  Below are the basic stages of the boot process:
> 	</para>
>-	 <para>
>-		Understanding how the boot and shutdown processes work not only allows customization, but also makes it easier to troubleshoot problems related to starting or shutting down the system.
>-	</para>
>-	 <section id="s1-boot-process-basics">
>-		<title>The Boot Process</title>
>-		 <indexterm significance="normal">
>-			<primary>boot process</primary>
>-			 <secondary>stages of</secondary>
>-
>-		</indexterm>
>-		 <para>
>-			Below are the basic stages of the boot process:
>+	<orderedlist continuation="restarts" inheritnum="ignore">
>+	  <listitem>
>+		<para>
>+		  The system loads and runs a boot loader. The specifics of this process depend on the system architecture. For example: 
> 		</para>
>-		 <orderedlist continuation="restarts" inheritnum="ignore">
>-			 <listitem>
>-				<para>
>-					The system loads and runs a boot loader. The specifics of this process depend on the system architecture. For example: 
>-				</para>
>-				<itemizedlist>
>-					<listitem>
>-						<para>
>-							BIOS-based x86 systems run a first-stage boot loader from the MBR of the primary hard disk that, in turn, loads an additional boot loader, <application>GRUB</application>. 
>-						</para>
>-					</listitem>
>-					<listitem>
>-						<para>
>-							UEFI-based x86 systems mount an EFI System Partition that contains a version of the <application>GRUB</application> boot loader. The EFI boot manager loads and runs <application>GRUB</application> as an EFI application.
>-						</para>
>-					</listitem>
>-				</itemizedlist>
>-			</listitem>
>-			 <listitem>
>-				<para>
>-					The boot loader loads the kernel and a small, read-only filesystem into memory. This filesystem, or initramfs, contains all the tools required for the kernel to continue the boot process.
>-				</para>
>-
>-			</listitem>
>-			 <listitem>
>-				<para>
>-					The kernel transfers control of the boot process to the system daemon, <application>systemd</application>.
>-				</para>
>-
>-			</listitem>
>-			 <listitem>
>-				<para>
>-					<application>systemd</application> loads needed services and user-space tools, and mounts  filesystems listed in <filename>/etc/fstab</filename>.
>-				</para>
>-
>-			</listitem>
>-			 <listitem>
>-				<para>
>-					The user is presented with a login screen for the freshly booted Linux system.
>-				</para>
>-
>-			</listitem>
>-
>-		</orderedlist>
>-		 <para>
>-			Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter discusses in detail how the boot process works and how it can be customized to suite specific needs.
>+		<itemizedlist>
>+		  <listitem>
>+			<para>
>+			  BIOS-based x86 systems run a first-stage boot loader from the MBR of the primary hard disk that, in turn, loads an additional boot loader, <application>GRUB</application>. 
>+			</para>
>+		  </listitem>
>+		  <listitem>
>+			<para>
>+			  UEFI-based x86 systems mount an EFI System Partition that contains a version of the <application>GRUB</application> boot loader. The EFI boot manager loads and runs <application>GRUB</application> as an EFI application.
>+			</para>
>+		  </listitem>
>+		</itemizedlist>
>+	  </listitem>
>+	  <listitem>
>+		<para>
>+		  The boot loader loads the kernel and a small, read-only filesystem into memory. This filesystem, or initramfs, contains all the tools required for the kernel to continue the boot process.
> 		</para>
>-
>-	</section>
>+        
>+	  </listitem>
>+	  <listitem>
>+		<para>
>+		  The kernel transfers control of the boot process to the system daemon, <application>systemd</application>.
>+		</para>
>+        
>+	  </listitem>
>+	  <listitem>
>+		<para>
>+		  <application>systemd</application> loads needed services and user-space tools, and mounts  filesystems listed in <filename>/etc/fstab</filename>.
>+		</para>
>+        
>+	  </listitem>
>+	  <listitem>
>+		<para>
>+		  The user is presented with a login screen for the freshly booted Linux system.
>+		</para>
>+        
>+	  </listitem>
>+      
>+	</orderedlist>
>+	<para>
>+	  Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter discusses in detail how the boot process works and how it can be customized to suite specific needs.
>+	</para>
>+    
>+  </section>
>+  
>+  <section id="s1-boot-init-shutdown-process">
>+	<title>A Detailed Look at the Boot Process</title>
>+	<indexterm significance="normal">
>+	  <primary>boot process</primary>
>+	  <secondary>for x86</secondary>
>+      
>+	</indexterm>
>+	<indexterm significance="normal">
>+	  <primary>boot process</primary>
>+	  <seealso>boot loaders</seealso>
>+      
>+	</indexterm>
>+	<indexterm significance="normal">
>+	  <primary>boot process</primary>
>+	  <secondary>stages of</secondary>
>+      
>+	</indexterm>
>+	<indexterm significance="normal">
>+	  <primary>Master Boot Record</primary>
>+	  <see>MBR</see>
>+      
>+	</indexterm>
>+	<indexterm significance="normal">
>+	  <primary>MBR</primary>
>+	  <secondary>definition of</secondary>
>+	  <seealso>boot process</seealso>
>+      
>+	</indexterm>
>+	<para>
>+	  The beginning of the boot process varies depending on the hardware platform being used. However, once the kernel is found and loaded by the boot loader, the default boot process is identical across all architectures. This chapter focuses primarily on the x86 architecture.
>+	</para>
> 	
>-	 <section id="s1-boot-init-shutdown-process">
>-		<title>A Detailed Look at the Boot Process</title>
>-		 <indexterm significance="normal">
>-			<primary>boot process</primary>
>-			 <secondary>for x86</secondary>
>-
>+	<section id="sect-firmware_interface">
>+	  <title>The firmware interface</title>
>+	  <section id="s2-boot-init-shutdown-bios">
>+		<title>BIOS-based x86 systems</title>
>+		<indexterm significance="normal">
>+		  <primary>Basic Input/Output System</primary>
>+		  <see>BIOS</see>
> 		</indexterm>
>-		 <indexterm significance="normal">
>-			<primary>boot process</primary>
>-			 <seealso>boot loaders</seealso>
>-
>+		<indexterm significance="normal">
>+		  <primary>BIOS</primary>
>+		  <secondary>definition of</secondary>
>+		  <seealso>boot process</seealso>
> 		</indexterm>
>-		 <indexterm significance="normal">
>-			<primary>boot process</primary>
>-			 <secondary>stages of</secondary>
>-
>+		<indexterm significance="normal">
>+		  <primary>Master Boot Record</primary>
>+		  <see>MBR</see>
> 		</indexterm>
>-		 <indexterm significance="normal">
>-			<primary>Master Boot Record</primary>
>-			 <see>MBR</see>
>-
>+		<indexterm significance="normal">
>+		  <primary>MBR</primary>
>+		  <secondary>definition of</secondary>
>+		  <seealso>boot loaders</seealso>
> 		</indexterm>
>-		 <indexterm significance="normal">
>-			<primary>MBR</primary>
>-			 <secondary>definition of</secondary>
>-			 <seealso>boot process</seealso>
>-
>+		<indexterm>
>+		  <primary>GUID Partition Table</primary>
>+		  <see>GPT</see>
> 		</indexterm>
>-		 <para>
>-			The beginning of the boot process varies depending on the hardware platform being used. However, once the kernel is found and loaded by the boot loader, the default boot process is identical across all architectures. This chapter focuses primarily on the x86 architecture.
>+		<indexterm significance="normal">
>+		  <primary>GPT</primary>
>+		  <secondary>definition of</secondary>
>+		</indexterm>
>+		<para>
>+		  The <firstterm>Basic Input/Output System</firstterm> (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it.
> 		</para>
>-	
>-		<section id="sect-firmware_interface">
>-		  <title>The firmware interface</title>
>-		  <section id="s2-boot-init-shutdown-bios">
>-		    <title>BIOS-based x86 systems</title>
>-		    <indexterm significance="normal">
>-		      <primary>Basic Input/Output System</primary>
>-		      <see>BIOS</see>
>-		    </indexterm>
>-		    <indexterm significance="normal">
>-		      <primary>BIOS</primary>
>-		      <secondary>definition of</secondary>
>-		      <seealso>boot process</seealso>
>-		    </indexterm>
>-		    <indexterm significance="normal">
>-		      <primary>Master Boot Record</primary>
>-		      <see>MBR</see>
>-		    </indexterm>
>-		    <indexterm significance="normal">
>-		      <primary>MBR</primary>
>-		      <secondary>definition of</secondary>
>-		      <seealso>boot loaders</seealso>
>-		    </indexterm>
>-		    <indexterm>
>-		      <primary>GUID Partition Table</primary>
>-		      <see>GPT</see>
>-		    </indexterm>
>-		    <indexterm significance="normal">
>-		      <primary>GPT</primary>
>-		      <secondary>definition of</secondary>
>-		    </indexterm>
>-		    <para>
>-		      The <firstterm>Basic Input/Output System</firstterm> (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it.
>-		    </para>
>-		    <para>
>-			Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks for bootable media in the specified order.
>-		    </para>
>-		    <para>
>-			A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <firstterm>GUID Partition Table</firstterm> (GPT). The <systemitem>MBR</systemitem> is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. The newer <systemitem>GPT</systemitem> serves the same role and allows for more and larger partitions, but is generally used on newer <systemitem>UEFI</systemitem> systems. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.
>-		    </para>
>-		    <para>
>-			This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (<application>GRUB</application>) and load the first part of it into memory.
>-		    </para>
>-		  </section>
>-		</section>
>-		<section id="s2-boot-init-shutdown-uefi">
>-		  <title>UEFI-based x86 systems</title>
>-		  <indexterm significance="normal">
>-		    <primary>Extensible Firmware Interface shell</primary>
>-		    <see>EFI shell</see>
>-		  </indexterm>
>-		  <indexterm significance="normal">
>-		    <primary>EFI shell</primary>
>-		    <seealso>boot process</seealso>
>-		  </indexterm>
>-		  <indexterm significance="normal">
>-		    <primary>boot process</primary>
>-		    <secondary>stages of</secondary>
>-		    <tertiary>EFI shell</tertiary>
>-		  </indexterm>
>-		  <para>
>-		    The <firstterm>Unified Extensible Firmware Interface</firstterm> (UEFI) is designed, like BIOS, to control the boot process (through <firstterm>boot services</firstterm>) and to provide an interface between system firmware and an operating system (through <firstterm>runtime services</firstterm>). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems. 
>-		  </para>
>-		  <para>
>+		<para>
>+		  Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks for bootable media in the specified order.
>+		</para>
>+		<para>
>+		  A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <firstterm>GUID Partition Table</firstterm> (GPT). The <systemitem>MBR</systemitem> is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. The newer <systemitem>GPT</systemitem> serves the same role and allows for more and larger partitions, but is generally used on newer <systemitem>UEFI</systemitem> systems. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.
>+		</para>
>+		<para>
>+		  This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (<application>GRUB</application>) and load the first part of it into memory.
>+		</para>
>+	  </section>
>+	</section>
>+	<section id="s2-boot-init-shutdown-uefi">
>+	  <title>UEFI-based x86 systems</title>
>+	  <indexterm significance="normal">
>+		<primary>Extensible Firmware Interface shell</primary>
>+		<see>EFI shell</see>
>+	  </indexterm>
>+	  <indexterm significance="normal">
>+		<primary>EFI shell</primary>
>+		<seealso>boot process</seealso>
>+	  </indexterm>
>+	  <indexterm significance="normal">
>+		<primary>boot process</primary>
>+		<secondary>stages of</secondary>
>+		<tertiary>EFI shell</tertiary>
>+	  </indexterm>
>+	  <para>
>+		The <firstterm>Unified Extensible Firmware Interface</firstterm> (UEFI) is designed, like BIOS, to control the boot process (through <firstterm>boot services</firstterm>) and to provide an interface between system firmware and an operating system (through <firstterm>runtime services</firstterm>). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems. 
>+	  </para>
>+	  <para>
> 		    When an x86 computer equipped with UEFI boots, the interface searches the system storage for a partition labeled with a specific <firstterm>globally unique identifier</firstterm> (GUID) that marks it as the <firstterm>EFI System Partition</firstterm> (ESP). This partition contains applications compiled for the EFI architecture, which might include bootloaders for operating systems and utility software. UEFI systems include an <firstterm>EFI boot manager</firstterm> that can boot the system from a default configuration, or prompt a user to choose an operating system to boot. When a bootloader is selected, manually or automatically, UEFI reads it into memory and yields control of the boot process to it.
>-		  </para>
>-		</section>
>-	      </section>
>-	      <section id="s2-boot-init-shutdown-loader">
>+	  </para>
>+	</section>
>+  </section>
>+  <section id="s2-boot-init-shutdown-loader">
> 		<title>The Boot Loader</title>
> 		<section id="s2-boot-init-shutdown-loader-bios">
> 		  <title>The GRUB boot loader for x86 systems</title>
>@@ -210,7 +210,7 @@
> 		    The bootloader is also used to pass arguments to the kernel it loads.  This allows the system to operate with a specified root filesystem, enable or disable kernel modules and system features, or configure booting to a specific runlevel. For instructions on using the boot loader to supply command line arguments to the kernel, refer to <xref linkend="ch-grub" />. Specific kernel parameters are described in <filename>/usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt</filename>, which is provided by the <package>kernel-doc</package> package. For information on changing the runlevel at the boot loader prompt, refer <xref linkend="s1-grub-runlevels" />.
> 		  </para>
> 		  <para>
>-		    The boot loader then places one or more appropriate <filename>initramfs</filename> images into memory. The <filename>initramfs</filename> is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 or ext4 file system.
>+		    The boot loader then places one or more appropriate <filename>initramfs</filename> images into memory. The <filename>initramfs</filename> is used by the kernel to load drivers and modules necessary to boot the system. 
> 		  </para>
> 		  <para>
> 		    Once the kernel and the <filename>initramfs</filename> image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel.
>@@ -222,7 +222,7 @@
> 		<section id="s3-boot-init-shutdown-other-architectures">
> 		  <title>Boot Loaders for Other Architectures</title>
> 		  <para>
>-		    Once the kernel loads and hands off the boot process to the <command>init</command> command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
>+		    Once the kernel loads and the boot process continues, the process of bringing up the system is the same. The main difference between each architecture's boot process is in the application used to find and load the kernel.
> 		  </para>
> 		  <para>
> 		    For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside the scope of this document.
>@@ -241,10 +241,9 @@
> 		  <secondary>role in boot process</secondary>
> 		</indexterm>
> 		<para>
>-		  When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed <filename>initramfs</filename> image(s) in a predetermined location in memory, decompresses it directly to <filename>/sysroot/</filename> via <command>cpio</command>, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID, before completing the <filename>initramfs</filename> processes and freeing up all the memory the disk image once occupied.
>+		  When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then loads the <filename>initramfs</filename> image(s) from disk and decompresses it into a <systemitem>tmpfs</systemitem> as the acting root filesystem.  The <filename>initramfs</filename> contains programs and kernel modules required to continue booting the system, such as those used to initialize virtual devices related to file systems, like LVM or software RAID.
> 		</para>
>-		<para>
>-		  The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory.
>+		<para>The kernel uses the <filename>initramfs</filename> to continue the boot process, and when the final root device is available, the <filename>initramfs</filename> is unmounted and the real root filesystem is mounted in it's place.
> 		</para>
> 		<para>
> 		  At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
>@@ -269,36 +268,112 @@
> 		<para>
> 		  <application>systemd</application> improves on other init systems by offering increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
> 		</para>
>-		
>-		<indexterm significance="normal">
>-		  <primary>cgroups</primary>
>-		  <secondary>use by <application>systemd</application></secondary>
>-		</indexterm>
>-		
>+			
> 		<itemizedlist>
> 		  <title> The Boot Process </title>
> 		  <listitem><para>
> 			A socket is created for each daemon that will be launched. The sockets allow daemons to communicate with each other and userspace programs. Because the sockets are abstracted from the processes that use them, interdependent services do not have to wait for each other to come up before sending messages to the socket.
> 		  </para></listitem>		       
>-		  
> 		  <listitem><para>
>-			New process started by <application>systemd</application> are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
>+			New process are started by <application>systemd</application>.
>+		  </para></listitem>
>+		  <listitem><para>
>+		    As they load, processes connect to their sockets and wait. <application>systemd</application> handles dependencies between programs, but does not need a preconfigured boot order. Userspace tools are loaded as the devices and services they depend on become available.
>+		  </para></listitem>
>+		  <listitem><para>
>+		    The user is presented with a login screen for the freshly booted Linux system.
> 		  </para></listitem>
> 		</itemizedlist>
>-		    
>+		<note>
>+           The processes are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
>+        </note>
> 	      </section>
> 	      
>-	      <section id="s2-boot-init-shutdown-systemd-units">
>-		<title><application>systemd</application> <function>units</function></title>     
>-		<indexterm significance="normal">
>-		  <primary><application>systemd</application></primary>
>-		  <secondary>units</secondary>
>-		</indexterm>
>+          <section id="s1-boot-init-shutdown-targets">
>+		    <title>systemd targets</title>
>+		 <indexterm significance="normal">
>+			<primary>systemd</primary>
>+			 <secondary><function>targets</function></secondary>
>+		 </indexterm>
>+		 <indexterm significance="normal">
>+		   <primary>runlevels</primary>
>+		 </indexterm>
>+		 <indexterm significance="normal">
>+		   <primary>cgroups</primary>
>+		   <secondary>use by <application>systemd</application></secondary>
>+		 </indexterm>
>+		   
>+		 <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. 
>+		   <para>
>+		     The system boots to the target described in <filename>/lib/systemd/system/default.target</filename>. This file is a symlink that can be changed when booting to a different target is desired. Appending <command>systemd.unit=<replaceable>custom</replaceable>.target</command> to the kernel's boot arguments will override the default target.
>+		   </para>
>+		   <para>
>+		     The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble and the use case they address.
>+		   </para>
>+		   <table>
>+		     <title>Predefined <application>systemd</application> targets</title>
>+		     <tgroup cols="3" align="left" colsep="1" rowsep="1">
>+		       <colspec colname="runlevel" colnum="1" />
>+		       <colspec colname="target" colnum="2" />
>+		       <colspec colname="usage" colnum="3" />
>+		       <thead>
>+		         <row>
>+			       <entry>Runlevel</entry>
>+			       <entry>Target</entry>
>+			       <entry>Usage</entry>
>+		         </row>
>+		       </thead>
>+		       <tbody>
>+		         <row>
>+			       <entry>1,single</entry>
>+			       <entry>rescue.target</entry>
>+			       <entry>single user mode, for recovery of critical system components or configuration</entry>
>+         	     </row>
>+                 <row>
>+                   <entry>3</entry>
>+                   <entry>multi-user.target</entry>
>+                   <entry>Non-graphical multi-user console access, via local TTYs or network.</entry>
>+                 </row>
>+                 <row>
>+                   <entry>5</entry>
>+                   <entry>graphical.target</entry>
>+                   <entry>A GUI session. Typically provides the user with a fully featured desktop environment.</entry>
>+                 </row>
>+                 <row>
>+                   <entry>4</entry>
>+                   <entry><replaceable>custom</replaceable>.target</entry>
>+                   <entry><application>systemd</application> allows any number of custom defined targets.</entry>
>+                 </row>
>+                 
>+		     </tbody>
>+		   </tgroup>
>+		 </table>
>+         
>+          </section>
> 		
>-		<para>
>+		 <section id="s2-boot-init-shutdown-systemd-management">
>+			<title>Runlevel Utilities</title>
>+			 <indexterm significance="normal">
>+				<primary>runlevels</primary>
>+				 <secondary>configuration of</secondary>
>+				 <seealso>services</seealso>
>+			 </indexterm>
>+             <para>
>+               <application>systemd</application> is administered using a number of utilities.
>+             </para>
>+		 </section>	      
>+
>+		 <section id="s2-boot-init-shutdown-systemd-units">
>+		   <title><application>systemd</application> <function>units</function></title>     
>+		   <indexterm significance="normal">
>+		     <primary><application>systemd</application></primary>
>+		     <secondary>units</secondary>
>+		   </indexterm>
>+		
>+		   <para>
> 			  Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
> Let's look at the different types of units:
>-		</para>
>+		   </para>
> 		    
> 		<segmentedlist>
> 		  <segtitle><function>unit</function> type</segtitle>
>@@ -362,8 +437,7 @@ Let's look at the different types of units:
> 			 
> 						 
> 			
>-			
>-			
>-		   <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble and the use case they address.
>-		 </para>
>-		 <table>
>-		   <title>Predefined <application>systemd</application> targets</title>
>-		   <tgroup cols="4" align="left" colsep="1" rowsep="1" />
>-		   <colspec colname="runlevel" colnum="1" />
>-		   <colspec colname="target" colnum="2" />
>-		   <colspec colname="usage" colnum="3" />
>-		   <colspec colname="member_units" colnum="4" />
>-		   <thead>
>-		     <row>
>-		       <entry>Runlevel</entry>
>-		       <entry>Target</entry>
>-		       <entry>Usage</entry>
>-		       <entry>Units</entry>
>-		     </row>
>-		   </thead>
>-		   <tbody>
>-		     <row>
>-		       <entry>1,single</entry>
>-		       <entry>rescue.target</entry>
>-		       <entry>single user mode, for recovery of critical system components or configuration</entry>
>-         	     </row>
>-		   </tbody>
>-		 </table>
> 
>-		</section>
>-		
>-		 <section id="s2-boot-init-shutdown-sysv-util">
>-			<title>Runlevel Utilities</title>
>-			 <indexterm significance="normal">
>-				<primary>runlevels</primary>
>-				 <secondary>configuration of</secondary>
>-				 <seealso>services</seealso>
>-			 </indexterm>
>+[Service]
>+ExecStart=/opt/domain/bin/example
>+Type=oneshot
>+
>+[Install]
>+WantedBy=multi-user.target
>+Alias=illustration.service
> 
>-		 </section>
>+		  </programlisting>
>+		</example>
>+		
>+		<para>
>+		  The <function>[Unit]</function> section has a shord description, and dependencies on other targets. The various types of dependencies and attributes used in this section are described in <command>man systemd.unit</command>
>+		</para>
>+		<para>
>+		  The <function>[Service]</function> section establishes the actual command to be executed, and describes how <application>systemd</application> should handle the process. Options for this section are described in <command>man systemd.service</command>.
>+		</para>
>+		<para>
>+		  The <function>[Install]</function> sets relationships with <function>targets</function> and similar behaviors. Options for this section are are also described in <command>man systemd.unit</command>
>+		</para>
>+		
>+		
>+	 </section>
>+	
>+	
> 		
> 
> 
>-- 
>1.7.11.7
>
>0014-Beginning-a-crash-course-in-systemctl.patch0000664000175000017500000002040212042420374020276 0ustar  petepeteFrom 393d0c6922decaa57f3953d914a5c9b8dd600d5c Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Fri, 21 Sep 2012 00:25:37 -0600
>Subject: [PATCH 14/17] Beginning a crash course in systemctl
>
>---
> en-US/Boot_Init_Shutdown.xml | 103 +++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 95 insertions(+), 8 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 577b832..2e61b11 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -228,8 +228,8 @@
> 		    For example, the IBM eServer pSeries architecture uses <application>yaboot</application>, and the IBM System&nbsp;z systems use the z/IPL boot loader. Configuration of alternative bootloaders is outside the scope of this document.
> 		  </para>
> 		</section>
>-	      </section>
>-	      <section id="s2-boot-init-shutdown-kernel">
>+	  </section>
>+	  <section id="s2-boot-init-shutdown-kernel">
> 		<title>The Kernel</title>
> 		<indexterm significance="normal">
> 		  <primary>boot process</primary>
>@@ -251,8 +251,8 @@
> 		<para>
> 		  To set up the user environment, the kernel executes the system daemon, <application>systemd</application>.
> 		</para>
>-	      </section>
>-	      <section id="s2-boot-init-shutdown-systemd">
>+	  </section>
>+	  <section id="s2-boot-init-shutdown-systemd">
> 		<title>Booting with <application>systemd</application></title>
> 		<indexterm significance="preferred">
> 		  <primary><application>systemd</application></primary>
>@@ -285,7 +285,10 @@
> 		  </para></listitem>
> 		</itemizedlist>
> 		<note>
>+		  <title>Control Groups</title>
>+		  <para>
>            The processes are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
>+		  </para>
>         </note>
> 	      </section>
> 	      
>@@ -302,8 +305,9 @@
> 		   <primary>cgroups</primary>
> 		   <secondary>use by <application>systemd</application></secondary>
> 		 </indexterm>
>-		   
>+		 <para>
> 		 <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. 
>+         </para>
> 		   <para>
> 		     The system boots to the target described in <filename>/lib/systemd/system/default.target</filename>. This file is a symlink that can be changed when booting to a different target is desired. Appending <command>systemd.unit=<replaceable>custom</replaceable>.target</command> to the kernel's boot arguments will override the default target.
> 		   </para>
>@@ -522,11 +526,94 @@ Alias=illustration.service
> 		
> 	 </section>
> 	
>-	
>-		
>+	<section id="s1-boot-init-shutdown-administration">
>+	  <title>Administering services with <application>systemd</application></title>
>+	  <indexterm significance="normal">
>+		<primary>systemd</primary>
>+		<secondary>administration utilites</secondary>
>+	  </indexterm>
>+	  
>+	  <indexterm>
>+		<primary>systemctl</primary>
>+	  </indexterm>
>+	  
>+	  <indexterm>
>+		<primary>chkconfig</primary>
>+		<see>systemctl</see>
>+	  </indexterm>
>+	  
>+	  <indexterm>
>+		<primary><command>service</command> command</primary>
>+		<see>systemctl</see>
>+	  </indexterm>
>+
>+	  
>+
>+	  <para>
>+		The move to <application>systemd</application> also brought new administration utilities to Fedora. Administrators have the ability to start, stop, and restart services as with <application>sysVinit</application>, but also have access to much more information and functionality. 
>+	  </para>
>+	  <warning>
>+		<title>Expect legacy commands to be depricated!</title>
>+		<para>
>+		  <command>systemctl</command> fully replaces traditional utilites like <command>service</command> and <command>chkconfig</command>. While some services can still be administered with these legacy commands, <emphasis>all</emphasis> services can be administered with <command>systemctl</command>.
>+		</para>
>+	  </warning>
>+
>+	  <para>
>+		<command>/usr/bin/systemctl</command> does most of the heavy lifting when starting and stopping services, or configuring them to run at boot. Let us look at what systemctl can do:
>+	  </para>
>+
>+          <section id="s1-boot-init-shutdown-administration-status">
>+            <title>Checking up on services</title>
>+            <screen>
>+
>+<![CDATA[
>+[root@fedora ~]# systemctl status sshd.service
>+sshd.service - OpenSSH server daemon
>+	  Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
>+	  Active: inactive (dead) since Thu, 20 Sep 2012 22:56:55 -0600; 17s ago
>+	 Process: 971 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
>+	 Process: 941 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
>+	  CGroup: name=systemd:/system/sshd.service
>+
>+Sep 20 19:17:02 fqdn.fedora.lan sshd[23515]: pam_unix(sshd:auth): authentication ...3
>+Sep 20 19:17:03 fqdn.fedora.lan sshd[23515]: Failed password for invalid user usr...2
>+Sep 20 19:17:04 fqdn.fedora.lan sshd[23515]: Received disconnect from 192.168.1.....]
>+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: Invalid user db2inst1 from 192.168.1...]
>+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: input_userauth_request: invalid user...]
>+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: pam_unix(sshd:auth): check pass; use...n
>+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: pam_unix(sshd:auth): authentication ...3
>+Sep 20 19:17:08 fqdn.fedora.lan sshd[23517]: Failed password for invalid user db2...2
>+Sep 20 19:17:08 fqdn.fedora.lan sshd[23517]: Received disconnect from 192.168.1.....]
>+Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
>+]]>
>+            </screen>
>+            <para>
>+            The command <command>systemctl status <replaceable>sshd</replaceable>.service</command> can tell us much more than if the service is running.  In this example with <application>sshd</application>, we can see that the service is <function>enabled</function> but not <function>active</function>. We know how the service was invoked, what the PID was, and when it was stopped. We can also see the last portion of the service's log.
>+            </para>
>+          </section>
>+          <section id="s1-boot-init-shutdown-administration-start">
>+            <title>Starting and stopping services</title>
>+            <screen><command>systemctl start sshd.service</command></screen>
>+            <screen><command>systemctl stop sshd.service</command></screen>
>+            <screen><command>systemctl restart sshd.service</command></screen>
>+
>+            <para>
>+              These commands will start, stop, and restart the service. The commands may not report the success or failure of the intended action, so we can check the status of the service with <command>systemctl status</command>. <application>systemctl</application> might report helpful information about a misbehaving application in the <function>status</function>, but the application's own logs are more relevant.
>+            </para>
>+          </section>
>+            <section id="s1-boot-init-shutdown-administration-enable">
>+              <title>Running services automatically</title>
>+              <screen><command>systemctl enable sshd.service</command></screen>
>+              <screen><command>systemctl disable sshd.service</command></screen>
>+              <para> 
>+                A service that is enabled will start automatically when the system boots. A service that is disabled will not start. These commands are manipulating symbolic links in <filename>/lib/systemd/system/</filename> and <filename>/lib/systemd/user/</filename>. While the symlinks can be manipulated manually, <application>systemctl</application> also rebuilds the <application>systemd</application> configuration, saving the extra step of invoking <command>systemctl daemon-reload</command>.
>+              </para>
>+            </section>
>+
>+
> 
> 
> 	
> 
> </appendix>
>-
>-- 
>1.7.11.7
>
>0015-added-some-debug-commands.patch0000664000175000017500000001234012042420374016023 0ustar  petepeteFrom 129955a4c98b8d21a3a9fb3b046bec024abb50db Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Tue, 2 Oct 2012 00:22:46 -0600
>Subject: [PATCH 15/17] added some debug commands
>
>---
> en-US/Boot_Init_Shutdown.xml | 58 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 56 insertions(+), 2 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index 2e61b11..a4c6851 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -607,13 +607,67 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
>               <screen><command>systemctl enable sshd.service</command></screen>
>               <screen><command>systemctl disable sshd.service</command></screen>
>               <para> 
>-                A service that is enabled will start automatically when the system boots. A service that is disabled will not start. These commands are manipulating symbolic links in <filename>/lib/systemd/system/</filename> and <filename>/lib/systemd/user/</filename>. While the symlinks can be manipulated manually, <application>systemctl</application> also rebuilds the <application>systemd</application> configuration, saving the extra step of invoking <command>systemctl daemon-reload</command>.
>+                A service that is enabled will start automatically when the system boots. A service that is disabled will not start at boot. These commands are manipulating symbolic links in <filename>/lib/systemd/system/</filename> and <filename>/lib/systemd/user/</filename> while retaining the relationships with other units established in the <filename>.service</filename> file. While the symlinks can be manipulated manually, <application>systemctl</application> also rebuilds the <application>systemd</application> configuration, saving the extra step of invoking <command>systemctl daemon-reload</command>.
>               </para>
>             </section>
>+            <section id="s1-boot-init-shutdown-administration-kill">
>+              <title>Killing and Masking services</title>
>+              <screen><command>systemctl kill sshd.service</command></screen>
>+              <screen><command>systemctl kill -s USR1 <replaceable>daemon</replaceable>.service</command></screen>
>+              <para>With the first command, <application>systemd</application> kills all processes and child processes of the <application>sshd</application> service. The second command demonstrates how any Unix signal can be sent to the processes of a service.
>+              </para>
>+              <screen><command>systemctl mask <replaceable>daemon</replaceable>.service</command></screen>
>+              <para>
>+                Masking a service prevents the service from being started manually or automatically. For this example, <application>systemctl</application> is creating a symlink from <filename>/etc/systemd/system/daemon.service</filename> to /dev/null. Targets in <filename>/etc/systemd</filename> override those provided by packages in <filename>/lib/systemd</filename>. <application>systemd</application> recognizes the symlink and will not start the service.
>+              </para>
>+            </section>
>+
>+	    <section id="s1-boot-init-shutdown-administration-systemctl">
>+	      <title>Getting more from <application>systemd</application></title>
>+	      <para>
>+		<application>systemctl</application> works with not only services but all other unit types, and is a valuable tool when monitoring or troubleshooting a system. It can list all known units, limit the results to a single unit type, show only failed units, or examine unit relationships. The table below shows some useful systemctl features.
>+              </para>
>+              <segmentedlist>
>+		<segtitle>command</segtitle>
>+		<segtitle>result</segtitle>
>+		<seglistitem>
>+		  <seg>systemctl list-jobs</seg>
>+		  <seg>
>+                    Shows running and waiting jobs; useful for troubleshooting during boot.
>+		  </seg>
>+		</seglistitem>
>+                <seglistitem>
>+                  <seg>systemctl list-units -t service</seg>
>+                  <seg>Shows all active services</seg>
>+                </seglistitem>
>+                <seglistitem>
>+                  <seg>systemctl list-units -t service --all</seg>
>+                  <seg>Shows all available services</seg>
>+                </seglistitem>
>+                <seglistitem>
>+                  <seg>systemctl show -p "Wants" multi-user.target</seg>
>+                  <seg>Shows which services are pulled in by a given target</seg>
>+                </seglistitem>
>+                <seglistitem>
>+                  <seg>systemd --test --system --unit=multi-user.target</seg>
>+                  <seg>Simulates booting the system to a given target</seg>
>+                </seglistitem>
>+                <seglistitem>
>+                  <seg>systemd-analyze plot > boot.svg</seg>
>+                  <seg>greates a graphical representation of the boot process</seg>
>+                </seglistitem>
>+              </segmentedlist>
>+                    
>+
>+
>+
> 
>+
> 
> 
>-
>+</section>
> 	
> 
> </appendix>
>-- 
>1.7.11.7
>
>0016-wrapping-up-with-systemd.patch0000664000175000017500000006055212042420374016057 0ustar  petepeteFrom c7a0bfb0cd8a3004174fc637f5baf130312e4495 Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Sun, 14 Oct 2012 23:35:04 -0600
>Subject: [PATCH 16/17] wrapping up with systemd
>
>---
> en-US/Boot_Init_Shutdown.xml | 445 +++++++++++++++++++++++++++++++++----------
> 1 file changed, 344 insertions(+), 101 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index a4c6851..f86ce87 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -70,7 +70,7 @@
>       
> 	</orderedlist>
> 	<para>
>-	  Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter discusses in detail how the boot process works and how it can be customized to suite specific needs.
>+	  Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter discusses in detail how the boot process works and how it can be customized to suit specific needs.
> 	</para>
>     
>   </section>
>@@ -213,7 +213,7 @@
> 		    The boot loader then places one or more appropriate <filename>initramfs</filename> images into memory. The <filename>initramfs</filename> is used by the kernel to load drivers and modules necessary to boot the system. 
> 		  </para>
> 		  <para>
>-		    Once the kernel and the <filename>initramfs</filename> image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel.
>+		    Once the kernel and the <filename>initramfs</filename> image(s) are loaded into memory, the boot loader hands control of the boot process to <application>systemd</application>.
> 		  </para>
> 		  <para>
> 		    For a more detailed overview of the GRUB boot loader, refer to <xref linkend="ch-grub" />.
>@@ -266,7 +266,7 @@
> 		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <application>SysVinit</application> program (also called <application>init</application>) and the newer <application>Upstart</application> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
> 		</para>
> 		<para>
>-		  <application>systemd</application> improves on other init systems by offering increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
>+		  <application>systemd</application> improves on other init systems with increased parallelization . It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
> 		</para>
> 			
> 		<itemizedlist>
>@@ -275,10 +275,10 @@
> 			A socket is created for each daemon that will be launched. The sockets allow daemons to communicate with each other and userspace programs. Because the sockets are abstracted from the processes that use them, interdependent services do not have to wait for each other to come up before sending messages to the socket.
> 		  </para></listitem>		       
> 		  <listitem><para>
>-			New process are started by <application>systemd</application>.
>+			New process are started by <application>systemd</application>.The processes are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
> 		  </para></listitem>
> 		  <listitem><para>
>-		    As they load, processes connect to their sockets and wait. <application>systemd</application> handles dependencies between programs, but does not need a preconfigured boot order. Userspace tools are loaded as the devices and services they depend on become available.
>+		    As they load, processes connect to their sockets to receive any waiting messages and communicate with other sockets. <application>systemd</application> handles dependencies between programs, but does not need a preconfigured boot order. Userspace tools are loaded as the devices and services they depend on become available.
> 		  </para></listitem>
> 		  <listitem><para>
> 		    The user is presented with a login screen for the freshly booted Linux system.
>@@ -287,7 +287,7 @@
> 		<note>
> 		  <title>Control Groups</title>
> 		  <para>
>-           The processes are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
>+           
> 		  </para>
>         </note>
> 	      </section>
>@@ -348,62 +348,48 @@
>                    <entry><replaceable>custom</replaceable>.target</entry>
>                    <entry><application>systemd</application> allows any number of custom defined targets.</entry>
>                  </row>
>-                 
>-		     </tbody>
>+		       </tbody>
> 		   </tgroup>
> 		 </table>
>          
>           </section>
>-		
>-		 <section id="s2-boot-init-shutdown-systemd-management">
>-			<title>Runlevel Utilities</title>
>-			 <indexterm significance="normal">
>-				<primary>runlevels</primary>
>-				 <secondary>configuration of</secondary>
>-				 <seealso>services</seealso>
>-			 </indexterm>
>-             <para>
>-               <application>systemd</application> is administered using a number of utilities.
>-             </para>
>-		 </section>	      
>-
>-		 <section id="s2-boot-init-shutdown-systemd-units">
>-		   <title><application>systemd</application> <function>units</function></title>     
>-		   <indexterm significance="normal">
>-		     <primary><application>systemd</application></primary>
>-		     <secondary>units</secondary>
>-		   </indexterm>
>-		
>-		   <para>
>-			  Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
>+	  
>+	  <section id="s2-boot-init-shutdown-systemd-units">
>+	    <title><application>systemd</application> <function>units</function></title>     
>+	    <indexterm significance="normal">
>+	      <primary><application>systemd</application></primary>
>+	      <secondary>units</secondary>
>+	    </indexterm>	
>+	    <para>
>+	      Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
> Let's look at the different types of units:
>-		   </para>
>-		    
>-		<segmentedlist>
>-		  <segtitle><function>unit</function> type</segtitle>
>-		  <segtitle>Role</segtitle>
>-		  <seglistitem>
>-		    <seg><function>socket</function></seg>
>-		    <seg>
>-		      These provide an endpoint for interprocesses communication. Messages can be transported through files, or network or unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
>-		    </seg>
>-		  </seglistitem>
>-		  
>-		  <seglistitem>
>-		    <seg><function>service</function></seg>
>-		    <seg>
>-			      These are traditional daemons. <function>Service</function> <function>units</function> are described in simple configuration files that define the type, execution, and envoronment of the program, as well as information regarding how <application>systemd</application> should monitor it.
>-		    </seg>
>-		  </seglistitem>
>-			    
>-		  <seglistitem>
>-		    <seg><function>device</function></seg>
>-		    <seg>
>-		      These are automatically created for all devices discovered by the kernel. These <function>units</function> are provided for services that are dependent on devices, or for virtual devices that are dependent on services, as with a network block device.
>-		    </seg>
>-		  </seglistitem>
>-		  
>-		  <seglistitem>
>+	    </para>
>+	    
>+	    <segmentedlist>
>+	      <segtitle><function>unit</function> type</segtitle>
>+	      <segtitle>Role</segtitle>
>+	      <seglistitem>
>+		<seg><function>socket</function></seg>
>+		<seg>
>+		  These provide an endpoint for interprocesses communication. Messages can be transported through files, or network or unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
>+		</seg>
>+	      </seglistitem>
>+	      
>+	      <seglistitem>
>+		<seg><function>service</function></seg>
>+		<seg>
>+		  These are traditional daemons. <function>Service</function> <function>units</function> are described in simple configuration files that define the type, execution, and envoronment of the program, as well as information regarding how <application>systemd</application> should monitor it.
>+		</seg>
>+	      </seglistitem>
>+	      
>+	      <seglistitem>
>+		<seg><function>device</function></seg>
>+		<seg>
>+		  These are automatically created for all devices discovered by the kernel. These <function>units</function> are provided for services that are dependent on devices, or for virtual devices that are dependent on services, as with a network block device.
>+		</seg>
>+	      </seglistitem>
>+	      
>+	      <seglistitem>
> 		    <seg><function>mount</function></seg>
> 		    <seg>
> 		      These <function>units</function> allow <application>systemd</application>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
>@@ -433,7 +419,7 @@ Let's look at the different types of units:
> 
> 		     
> 		<para>
>-		  Although <application>systemd</application> <function>units</function> will ultimately be available for all services, it retains support for legacy init scripts. <function>units</function> are dynamically created for these services, with dependencies inferred from LSB headers in the script. There are drawbacks to this method, so it is best to have a native <application>systemd</application> <function>unit</function> file.
>+		  Although <application>systemd</application> <function>units</function> will ultimately be available for all services, it retains support for legacy init scripts. <function>units</function> are dynamically created for services without native configurations, with dependencies inferred from LSB headers in the script. There are drawbacks to this method, so it is best to have a native <application>systemd</application> <function>unit</function> file.
> 		</para>
> 		<para>
> 		  The function and usage of legacy init systems and their configuration files is outside of the scope of this document.
>@@ -624,50 +610,307 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
> 
> 	    <section id="s1-boot-init-shutdown-administration-systemctl">
> 	      <title>Getting more from <application>systemd</application></title>
>+
> 	      <para>
>-		<application>systemctl</application> works with not only services but all other unit types, and is a valuable tool when monitoring or troubleshooting a system. It can list all known units, limit the results to a single unit type, show only failed units, or examine unit relationships. The table below shows some useful systemctl features.
>+		<application>systemctl</application> works with not only services but all other unit types, and is a valuable tool when monitoring or troubleshooting a system. It can list all known units, limit the results to a single unit type, show only failed units, or examine unit relationships. The table below shows some useful systemctl features and should help system administrators replace their old workflow in <application>sysVinit</application>.
>               </para>
>-              <segmentedlist>
>-		<segtitle>command</segtitle>
>-		<segtitle>result</segtitle>
>-		<seglistitem>
>-		  <seg>systemctl list-jobs</seg>
>-		  <seg>
>-                    Shows running and waiting jobs; useful for troubleshooting during boot.
>-		  </seg>
>-		</seglistitem>
>-                <seglistitem>
>-                  <seg>systemctl list-units -t service</seg>
>-                  <seg>Shows all active services</seg>
>-                </seglistitem>
>-                <seglistitem>
>-                  <seg>systemctl list-units -t service --all</seg>
>-                  <seg>Shows all available services</seg>
>-                </seglistitem>
>-                <seglistitem>
>-                  <seg>systemctl show -p "Wants" multi-user.target</seg>
>-                  <seg>Shows which services are pulled in by a given target</seg>
>-                </seglistitem>
>-                <seglistitem>
>-                  <seg>systemd --test --system --unit=multi-user.target</seg>
>-                  <seg>Simulates booting the system to a given target</seg>
>-                </seglistitem>
>-                <seglistitem>
>-                  <seg>systemd-analyze plot > boot.svg</seg>
>-                  <seg>greates a graphical representation of the boot process</seg>
>-                </seglistitem>
>-              </segmentedlist>
>+              <table>
>+		<title><application>systemd</application> command reference</title>
>+		<tgroup cols='3'>
>+		  <colspec colname='sysv' />
>+		  <colspec colname='systemd' />
>+		  <colspec colname='notes' />
>+		  <thead>
>+		    <row>
>+		      <entry>
>+			<application>sysVinit</application> command
>+		      </entry>
>+                      <entry>
>+                        <application>systemd</application> command
>+                      </entry>
>+                      <entry>
>+                        Notes
>+                      </entry>
>+                    </row>
>+                  </thead>
>+                  <tbody>
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          service sshd start
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl start sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Used to start a service (not reboot persistent)
>+                      </entry>
>+                    </row>
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          service sshd stop
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl stop sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Used to stop a service. (not reboot persistent)
>+                      </entry>
>+                    </row>
>                     
>+		 <row>
>+                      <entry>
>+                        <command>
>+                          service sshd restart
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl restart sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Used to start and stop a service.
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          service sshd reload
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl reload sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        When supported, reloads the config file without interrupting pending operations.
>+                      </entry>
>+                    </row>
>+	            <row>
>+                      <entry>
>+                        <command>
>+                          service sshd condrestart
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl condrestart sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Restarts if the service is already running.
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          service sshd status
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl status sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Tells whether a service is currently running.
>+                      </entry>
>+                    </row>
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          ls /etc/rc.d/init.d/
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl list-unit-files --type=service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Lists all available services.
>+                      </entry>
>+                    </row>
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          chkconfig sshd on
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl enable sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Always run the service at this target (runlevel.)
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          chkconfig sshd off
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl disable sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Do not automatically run the service at this target (runlevel.)
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          chkconfig --list
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl list-units -t service --all
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Print a table of available services and their status.
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          chkconfig sshd --list
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          ls /etc/systemd/system/*.wants/sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Lists the targets that will include the service.
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          chkconfig sshd --add
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl daemon-reload
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Used when you create a service file or modify any configuration.
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+                          telinit 3
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl isolate multi-user.target
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Move system into another target (change runlevels.)
>+                      </entry>
>+                    </row>
>+<row>
>+                      <entry>
>+                        <command>
>+                          [no comparable command]
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemctl show -p "Wants" multi-user.target
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Lists units pulled in by a given target.
>+                      </entry>
>+                    </row> 
>+		     <row>
>+                      <entry>
>+                        <command>
>+			  [no comparable command]
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+			  systemctl show -p "After" sshd.service
>+                        </command>
>+                      </entry>
>+                      <entry>
>+			Shows dependent services and other targets.
>+                      </entry>
>+                    </row>
> 
>-
>-
>-
>-
>-
>-
>-</section>
>-	
>-
>-</appendix>
>+		    <row>
>+                      <entry>
>+                        <command>
>+                          [no comparable command]
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+                          systemd --test --system --unit=multi-user.target
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        Simulates booting the system to a given target
>+                      </entry>
>+                    </row> 
>+                    <row>
>+                      <entry>
>+                        <command>
>+			  [no comparable command]
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+			  systemd-analyze plot > boot.svg
>+                        </command>
>+                      </entry>
>+                      <entry>
>+			Generates a diagnostically useful graphical representation of the boot process.
>+                      </entry>
>+                    </row> 
>+		    <row>
>+                      <entry>
>+                        <command>
>+			  ps xawf -eo pid,user,cgroup,args
>+                        </command>
>+                      </entry>
>+                      <entry>
>+                        <command>
>+			  systemd-cgls
>+                        </command>
>+                      </entry>
>+                      <entry>
>+			Display control group process tree.
>+                      </entry>
>+                    </row>
>+		  </tbody>
>+		</tgroup>
>+		</table>
>+	      </section>
>+	    </section>
>+	    
>+	    
>+	  </appendix>
>-- 
>1.7.11.7
>
>0017-correcting-some-typos-and-tags-in-init-section.patch0000664000175000017500000006666512042420374022142 0ustar  petepeteFrom d9d6360351150b593475731d735c3ce27b651c6e Mon Sep 17 00:00:00 2001
>From: Pete Travis <immanetize@fedoraproject.org>
>Date: Thu, 25 Oct 2012 23:31:44 -0600
>Subject: [PATCH 17/17] correcting some typos and tags in init section
>
>---
> en-US/Boot_Init_Shutdown.xml | 208 +++++++++++++++++++------------------------
> 1 file changed, 92 insertions(+), 116 deletions(-)
>
>diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
>index f86ce87..73b5cfc 100644
>--- a/en-US/Boot_Init_Shutdown.xml
>+++ b/en-US/Boot_Init_Shutdown.xml
>@@ -177,28 +177,28 @@
>   <section id="s2-boot-init-shutdown-loader">
> 		<title>The Boot Loader</title>
> 		<section id="s2-boot-init-shutdown-loader-bios">
>-		  <title>The GRUB boot loader for x86 systems</title>
>+		  <title>The GRUB2 boot loader for x86 systems</title>
> 		  <indexterm significance="normal">
> 		    <primary>boot process</primary>
> 		    <secondary>stages of</secondary>
> 		    <tertiary>boot loader</tertiary>
> 		  </indexterm>
> 		  <indexterm significance="normal">
>-		    <primary>GRUB</primary>
>+		    <primary>GRUB2</primary>
> 		    <secondary>role in boot process</secondary>
> 		  </indexterm>
> 		  <indexterm significance="normal">
>-		    <primary>GRUB</primary>
>+		    <primary>GRUB2</primary>
> 		    <seealso>boot loaders</seealso>
> 		  </indexterm>
> 		  <para>
>-		    The system loads GRUB into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI.
>+		    The system loads GRUB2 into memory, as directed by either a first-stage bootloader in the case of systems equipped with BIOS, or read directly from an EFI System Partition in the case of systems equipped with UEFI.
> 		  </para>
> 		  <para>
>-		    <application>GRUB</application> version 2 has the advantage of being able to read a variety of open filesystems, as well as virtual devices such as <application>mdadm</application> RAID arrays and <application>LVM</application> .
>+		    <application>GRUB2</application> has the advantage of being able to read a variety of open filesystems, as well as virtual devices such as <application>mdadm</application> RAID arrays and <application>LVM</application> .
> 		  </para>
> 		  <para>
>-		    GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
>+		    GRUB2 mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; at boot time. Refer to <xref linkend="s1-grub-configfile" /> for information on how to edit this file.
> 		  </para>
> 		  <para>
> 		    Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot (when you update the kernel, the boot loader configuration file is updated automatically). On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press <keycap>Enter</keycap>. Typically, if no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.
>@@ -216,7 +216,7 @@
> 		    Once the kernel and the <filename>initramfs</filename> image(s) are loaded into memory, the boot loader hands control of the boot process to <application>systemd</application>.
> 		  </para>
> 		  <para>
>-		    For a more detailed overview of the GRUB boot loader, refer to <xref linkend="ch-grub" />.
>+		    For a more detailed overview of the GRUB2 boot loader, refer to <xref linkend="ch-grub" />.
> 		  </para>
> 		</section>
> 		<section id="s3-boot-init-shutdown-other-architectures">
>@@ -243,7 +243,7 @@
> 		<para>
> 		  When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then loads the <filename>initramfs</filename> image(s) from disk and decompresses it into a <systemitem>tmpfs</systemitem> as the acting root filesystem.  The <filename>initramfs</filename> contains programs and kernel modules required to continue booting the system, such as those used to initialize virtual devices related to file systems, like LVM or software RAID.
> 		</para>
>-		<para>The kernel uses the <filename>initramfs</filename> to continue the boot process, and when the final root device is available, the <filename>initramfs</filename> is unmounted and the real root filesystem is mounted in it's place.
>+		<para>The kernel uses the <filename>initramfs</filename> to continue the boot process, and when the final root device is available, the <filename>initramfs</filename> is unmounted and the real root filesystem is mounted in its place.
> 		</para>
> 		<para>
> 		  At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
>@@ -266,7 +266,7 @@
> 		    <application>systemd</application> is the first process started by the kernel. It replaces the venerable <application>SysVinit</application> program (also called <application>init</application>) and the newer <application>Upstart</application> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
> 		</para>
> 		<para>
>-		  <application>systemd</application> improves on other init systems with increased parallelization . It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
>+		  <application>systemd</application> improves on other init systems with increased parallelization. It starts the process of loading all programs it launches immediately, and manages information between interdependent programs as they load. By dissociating programs and their means of communication, each program is able to load without waiting for unrelated or even dependent programs to load first.
> 		</para>
> 			
> 		<itemizedlist>
>@@ -275,7 +275,7 @@
> 			A socket is created for each daemon that will be launched. The sockets allow daemons to communicate with each other and userspace programs. Because the sockets are abstracted from the processes that use them, interdependent services do not have to wait for each other to come up before sending messages to the socket.
> 		  </para></listitem>		       
> 		  <listitem><para>
>-			New process are started by <application>systemd</application>.The processes are assigned to <function>Control Groups</function>, or <function> cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources alloted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
>+			New processes are started by <application>systemd</application>.The processes are assigned to <function>Control Groups</function>, or <function>cgroups</function>. Processes in a <function>cgroup</function> are isolated to resources allotted by the kernel, and the restrictions are inherited by newly spawned processes. Communication with outside processes will be handled by the kernel through sockets.
> 		  </para></listitem>
> 		  <listitem><para>
> 		    As they load, processes connect to their sockets to receive any waiting messages and communicate with other sockets. <application>systemd</application> handles dependencies between programs, but does not need a preconfigured boot order. Userspace tools are loaded as the devices and services they depend on become available.
>@@ -284,75 +284,7 @@
> 		    The user is presented with a login screen for the freshly booted Linux system.
> 		  </para></listitem>
> 		</itemizedlist>
>-		<note>
>-		  <title>Control Groups</title>
>-		  <para>
>-           
>-		  </para>
>-        </note>
>-	      </section>
>-	      
>-          <section id="s1-boot-init-shutdown-targets">
>-		    <title>systemd targets</title>
>-		 <indexterm significance="normal">
>-			<primary>systemd</primary>
>-			 <secondary><function>targets</function></secondary>
>-		 </indexterm>
>-		 <indexterm significance="normal">
>-		   <primary>runlevels</primary>
>-		 </indexterm>
>-		 <indexterm significance="normal">
>-		   <primary>cgroups</primary>
>-		   <secondary>use by <application>systemd</application></secondary>
>-		 </indexterm>
>-		 <para>
>-		 <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. 
>-         </para>
>-		   <para>
>-		     The system boots to the target described in <filename>/lib/systemd/system/default.target</filename>. This file is a symlink that can be changed when booting to a different target is desired. Appending <command>systemd.unit=<replaceable>custom</replaceable>.target</command> to the kernel's boot arguments will override the default target.
>-		   </para>
>-		   <para>
>-		     The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble and the use case they address.
>-		   </para>
>-		   <table>
>-		     <title>Predefined <application>systemd</application> targets</title>
>-		     <tgroup cols="3" align="left" colsep="1" rowsep="1">
>-		       <colspec colname="runlevel" colnum="1" />
>-		       <colspec colname="target" colnum="2" />
>-		       <colspec colname="usage" colnum="3" />
>-		       <thead>
>-		         <row>
>-			       <entry>Runlevel</entry>
>-			       <entry>Target</entry>
>-			       <entry>Usage</entry>
>-		         </row>
>-		       </thead>
>-		       <tbody>
>-		         <row>
>-			       <entry>1,single</entry>
>-			       <entry>rescue.target</entry>
>-			       <entry>single user mode, for recovery of critical system components or configuration</entry>
>-         	     </row>
>-                 <row>
>-                   <entry>3</entry>
>-                   <entry>multi-user.target</entry>
>-                   <entry>Non-graphical multi-user console access, via local TTYs or network.</entry>
>-                 </row>
>-                 <row>
>-                   <entry>5</entry>
>-                   <entry>graphical.target</entry>
>-                   <entry>A GUI session. Typically provides the user with a fully featured desktop environment.</entry>
>-                 </row>
>-                 <row>
>-                   <entry>4</entry>
>-                   <entry><replaceable>custom</replaceable>.target</entry>
>-                   <entry><application>systemd</application> allows any number of custom defined targets.</entry>
>-                 </row>
>-		       </tbody>
>-		   </tgroup>
>-		 </table>
>-         
>-          </section>
>+	  </section>	
> 	  
> 	  <section id="s2-boot-init-shutdown-systemd-units">
> 	    <title><application>systemd</application> <function>units</function></title>     
>@@ -361,7 +293,7 @@
> 	      <secondary>units</secondary>
> 	    </indexterm>	
> 	    <para>
>-	      Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is decribed in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and it's dependencies.
>+	      Functions administered by <application>systemd</application> are referred to as <function>units</function>. Each <function>unit</function> has a name and a type, and is described in a file that follows the convention of <replaceable>unit-name</replaceable>.<replaceable>type</replaceable>. The configuration file defines the relationship between a <function>unit</function> and its dependencies.
> Let's look at the different types of units:
> 	    </para>
> 	    
>@@ -371,7 +303,7 @@ Let's look at the different types of units:
> 	      <seglistitem>
> 		<seg><function>socket</function></seg>
> 		<seg>
>-		  These provide an endpoint for interprocesses communication. Messages can be transported through files, or network or unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
>+		  These provide an endpoint for interprocess communication. Messages can be transported through files, or network or Unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
> 		</seg>
> 	      </seglistitem>
> 	      
>@@ -406,7 +338,7 @@ Let's look at the different types of units:
> 		  <seglistitem>
> 		    <seg><function>target</function></seg>
> 		    <seg>
>-			      These are logical groupings of <function>units</function> that are required for userspace functionality. Some are large, such as <filename>multi-user.target</filename> that defines a full graphical user environment, or more topical, such as <filename>bluetooth.target</filename> that provides the services a user expects to be available when using bluetooth devices.
>+			      These are logical groupings of <function>units</function> that are required for userspace functionality. Some are large, such as <filename>multi-user.target</filename>, which defines a full graphical user environment, or more topical, such as <filename>bluetooth.target</filename>, which provides the services a user expects to be available when using Bluetooth devices.
> 		    </seg>
> 		  </seglistitem>
> 
>@@ -427,27 +359,71 @@ Let's look at the different types of units:
> 			 
> 						 
> 			
>-						
>-
>-
>-	</section>
>-	
>+			
>+			
>+		      </section>
>+		      
>+          <section id="s1-boot-init-shutdown-targets">
>+		    <title>systemd targets</title>
>+		 <indexterm significance="normal">
>+			<primary>systemd</primary>
>+			 <secondary><function>targets</function></secondary>
>+		 </indexterm>
>+		 <indexterm significance="normal">
>+		   <primary>runlevels</primary>
>+		 </indexterm>
>+		 <indexterm significance="normal">
>+		   <primary>cgroups</primary>
>+		   <secondary>use by <application>systemd</application></secondary>
>+		 </indexterm>
>+		 <para>
>+		 <application>systemd</application> replaces traditional <application>SysVinit</application> <function>runlevels</function> with predefined groups of <function>units</function> called <function>targets</function>. <function>Targets</function> are usually defined according to the intended use of the system, and ensure that required dependencies for that use are met. 
>+         </para>
>+		   <para>
>+		     The system boots to the target described in <filename>/lib/systemd/system/default.target</filename>. This file is a symlink that can be changed when booting to a different target is desired. Appending <command>systemd.unit=<replaceable>custom</replaceable>.target</command> to the kernel's boot arguments will override the default target.
>+		   </para>
>+		   <para>
>+		     The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble and the use case they address.
>+		   </para>
>+		   <table>
>+		     <title>Predefined <application>systemd</application> targets</title>
>+		     <tgroup cols="3" align="left" colsep="1" rowsep="1">
>+		       <colspec colname="runlevel" colnum="1" />
>+		       <colspec colname="target" colnum="2" />
>+		       <colspec colname="usage" colnum="3" />
>+		       <thead>
>+		         <row>
>+			       <entry>Runlevel</entry>
>+			       <entry>Target</entry>
>+			       <entry>Usage</entry>
>+		         </row>
>+		       </thead>
>+		       <tbody>
>+		         <row>
>+			       <entry>1,single</entry>
>+			       <entry>rescue.target</entry>
>+			       <entry>single user mode, for recovery of critical system components or configuration</entry>
>+         	     </row>
>+                 <row>
>+                   <entry>3</entry>
>+                   <entry>multi-user.target</entry>
>+                   <entry>Non-graphical multi-user console access, via local TTYs or network.</entry>
>+                 </row>
>+                 <row>
>+                   <entry>5</entry>
>+                   <entry>graphical.target</entry>
>+                   <entry>A GUI session. Typically provides the user with a fully featured desktop environment.</entry>
>+                 </row>
>+                 <row>
>+                   <entry>4</entry>
>+                   <entry><replaceable>custom</replaceable>.target</entry>
>+                   <entry><application>systemd</application> allows any number of custom defined targets.</entry>
>+                 </row>
>+		       </tbody>
>+		   </tgroup>
>+		 </table>
>+         
>+          </section>
> 	 <section id="s1-boot-init-shutdown-run-boot">
> 		<title>Running Additional Programs at Boot Time</title>
> 		 <indexterm significance="normal">
>@@ -500,7 +476,7 @@ Alias=illustration.service
> 		</example>
> 		
> 		<para>
>-		  The <function>[Unit]</function> section has a shord description, and dependencies on other targets. The various types of dependencies and attributes used in this section are described in <command>man systemd.unit</command>
>+		  The <function>[Unit]</function> section has a short description, and dependencies on other targets. The various types of dependencies and attributes used in this section are described in <command>man systemd.unit</command>
> 		</para>
> 		<para>
> 		  The <function>[Service]</function> section establishes the actual command to be executed, and describes how <application>systemd</application> should handle the process. Options for this section are described in <command>man systemd.service</command>.
>@@ -539,14 +515,14 @@ Alias=illustration.service
> 		The move to <application>systemd</application> also brought new administration utilities to Fedora. Administrators have the ability to start, stop, and restart services as with <application>sysVinit</application>, but also have access to much more information and functionality. 
> 	  </para>
> 	  <warning>
>-		<title>Expect legacy commands to be depricated!</title>
>+		<title>Expect legacy commands to be deprecated!</title>
> 		<para>
> 		  <command>systemctl</command> fully replaces traditional utilites like <command>service</command> and <command>chkconfig</command>. While some services can still be administered with these legacy commands, <emphasis>all</emphasis> services can be administered with <command>systemctl</command>.
> 		</para>
> 	  </warning>
> 
> 	  <para>
>-		<command>/usr/bin/systemctl</command> does most of the heavy lifting when starting and stopping services, or configuring them to run at boot. Let us look at what systemctl can do:
>+		<application>/usr/bin/systemctl</application> does most of the heavy lifting when starting and stopping services, or configuring them to run at boot. Let us look at what <application>systemctl</application> can do:
> 	  </para>
> 
>           <section id="s1-boot-init-shutdown-administration-status">
>@@ -585,7 +561,7 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
>             <screen><command>systemctl restart sshd.service</command></screen>
> 
>             <para>
>-              These commands will start, stop, and restart the service. The commands may not report the success or failure of the intended action, so we can check the status of the service with <command>systemctl status</command>. <application>systemctl</application> might report helpful information about a misbehaving application in the <function>status</function>, but the application's own logs are more relevant.
>+              These commands will start, stop, and restart the service. The commands may not report the success or failure of the intended action, so we can check the status of the service with <command>systemctl status</command>. <command>systemctl</command> might report helpful information about a misbehaving application in the <function>status</function>, but the application's own logs are more relevant.
>             </para>
>           </section>
>             <section id="s1-boot-init-shutdown-administration-enable">
>@@ -593,29 +569,29 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
>               <screen><command>systemctl enable sshd.service</command></screen>
>               <screen><command>systemctl disable sshd.service</command></screen>
>               <para> 
>-                A service that is enabled will start automatically when the system boots. A service that is disabled will not start at boot. These commands are manipulating symbolic links in <filename>/lib/systemd/system/</filename> and <filename>/lib/systemd/user/</filename> while retaining the relationships with other units established in the <filename>.service</filename> file. While the symlinks can be manipulated manually, <application>systemctl</application> also rebuilds the <application>systemd</application> configuration, saving the extra step of invoking <command>systemctl daemon-reload</command>.
>+                A service that is enabled will start automatically when the system boots. A service that is disabled will not start at boot. These commands are manipulating symbolic links in <filename>/lib/systemd/system/</filename> and <filename>/lib/systemd/user/</filename> while retaining the relationships with other units established in the <filename>.service</filename> file. While the symlinks can be manipulated manually, <command>systemctl</command> also rebuilds the <application>systemd</application> configuration, saving the extra step of invoking <command>systemctl daemon-reload</command>.
>               </para>
>             </section>
>             <section id="s1-boot-init-shutdown-administration-kill">
>               <title>Killing and Masking services</title>
>               <screen><command>systemctl kill sshd.service</command></screen>
>               <screen><command>systemctl kill -s USR1 <replaceable>daemon</replaceable>.service</command></screen>
>-              <para>With the first command, <application>systemd</application> kills all processes and child processes of the <application>sshd</application> service. The second command demonstrates how any Unix signal can be sent to the processes of a service.
>+              <para>With the first command, <command>systemd</command> kills all processes and child processes of the <application>sshd</application> service. The second command demonstrates how any Unix signal can be sent to the processes of a service.
>               </para>
>-              <screen><command>systemctl mask <replaceable>daemon</replaceable>.service</command></screen>
>+              <screen><command>systemctl mask <replaceable>sshd</replaceable>.service</command></screen>
>               <para>
>-                Masking a service prevents the service from being started manually or automatically. For this example, <application>systemctl</application> is creating a symlink from <filename>/etc/systemd/system/daemon.service</filename> to /dev/null. Targets in <filename>/etc/systemd</filename> override those provided by packages in <filename>/lib/systemd</filename>. <application>systemd</application> recognizes the symlink and will not start the service.
>+                Masking a service prevents the service from being started manually or automatically. For this example, <command>systemctl</command> is creating a symlink from <filename>/etc/systemd/system/sshd.service</filename> to <filename>/dev/null</filename>. Targets in <filename>/etc/systemd</filename> override those provided by packages in <filename>/lib/systemd</filename>. <command>systemd</command> recognizes the symlink and will not start the service.
>               </para>
>             </section>
> 
> 	    <section id="s1-boot-init-shutdown-administration-systemctl">
>-	      <title>Getting more from <application>systemd</application></title>
>+	      <title>Getting more from <command>systemd</command></title>
> 
> 	      <para>
>-		<application>systemctl</application> works with not only services but all other unit types, and is a valuable tool when monitoring or troubleshooting a system. It can list all known units, limit the results to a single unit type, show only failed units, or examine unit relationships. The table below shows some useful systemctl features and should help system administrators replace their old workflow in <application>sysVinit</application>.
>+		<command>systemctl</command> works with not only services but all other unit types, and is a valuable tool when monitoring or troubleshooting a system. It can list all known units, limit the results to a single unit type, show only failed units, or examine unit relationships. The table below shows some useful <command>systemctl</command> features and should help system administrators replace their old workflow in <application>sysVinit</application>.
>               </para>
>               <table>
>-		<title><application>systemd</application> command reference</title>
>+		<title><command>systemd</command> command reference</title>
> 		<tgroup cols='3'>
> 		  <colspec colname='sysv' />
> 		  <colspec colname='systemd' />
>@@ -623,10 +599,10 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
> 		  <thead>
> 		    <row>
> 		      <entry>
>-			<application>sysVinit</application> command
>+			<command>sysVinit</command> command
> 		      </entry>
>                       <entry>
>-                        <application>systemd</application> command
>+                        <command>systemd</command> command
>                       </entry>
>                       <entry>
>                         Notes
>-- 
>1.7.11.7
>
>systemd-revised-to-master.patch0000664000175000017500000000166012042420374015616 0ustar  petepetepatch/0001-mentioning-the-initramfs.patch
>patch/0002-gave-systemd-some-credit-in-the-boot-overview.patch
>patch/0003-Removed-admonition-regarding-grub-s-limited-filesyst.patch
>patch/0004-added-a-refererence-for-kernel-parameters.patch
>patch/0005-we-might-mention-there-are-alternative-bootloaders-w.patch
>patch/0006-added-an-intro-to-systemd-and-described-unit-types.patch
>patch/0007-correcting-some-tags.patch
>patch/0008-comments-on-filesystems-supported-by-grub.patch
>patch/0009-Added-a-few-comments-about-GPT.patch
>patch/0010-added-comments-on-systemd-compatibility-with-legacy-.patch
>patch/0011-purging-out-legacy-init-scripts-info.patch
>patch/0012-tag-cleanup.patch
>patch/0013-Added-systemd-target-description-minor-changes-in-ot.patch
>patch/0014-Beginning-a-crash-course-in-systemctl.patch
>patch/0015-added-some-debug-commands.patch
>patch/0016-wrapping-up-with-systemd.patch
>patch/0017-correcting-some-typos-and-tags-in-init-section.patch
>

Actions: View | Diff

Attachments on bug 829233: 627447 | 633641