Small improvements on docs

README.md

@@ -12,13 +12,13 @@ There are a few live distibutions which support the UEFI Secure Boot (Debian liv
 
 The aim of the liveng project is to give the Community a set of best practices in order to transform a common Debian Linux live into a live(ng) operating system which does:
 
-* encrypted persistence;
+* native encrypted persistence;
 * kernel update (on a live ISO 9660 filesystem!);
-* UEFI, with UEFI Secure Boot compatibility.
+* UEFI, with UEFI Secure Boot compatibility, with a real efi partition.
 
 As the base of liveng we have chosen the Debian Stretch live distribution.
 
 This Github repository hosts:
 
-    * source documentation files for Read the Docs, liveng.readthedocs.io
-    * a set of proof-of-concepts scripts
+* source documentation files for Read the Docs, see https://liveng.readthedocs.io;
+* a set of proof-of-concepts scripts.

docs/source/index.rst

@@ -13,9 +13,9 @@ There are a few live distibutions which support the UEFI Secure Boot (Debian liv
 
 The aim of the liveng project is to give the Community a set of best practices in order to transform a common Debian Linux live into a live(ng) operating system which does:
 
-* encrypted persistence natively;
+* native encrypted persistence;
 * kernel update (on a live ISO 9660 filesystem!);
-* UEFI, with UEFI Secure Boot compatibility with a real efi partition.
+* UEFI, with UEFI Secure Boot compatibility, with a real efi partition.
 
 As the base of liveng we have chosen the Debian Stretch live distribution.
 

docs/source/setup.rst

@@ -6,7 +6,7 @@ All the steps needed to write a standard Debian Stretch live operating system im
 * download the iso-hybrid live image from: https://cdimage.debian.org/debian-cd/current-live/ for your PC's architecture, i386 or amd64;
 * plug the USB key into your computer running any Linux-based OS (I am using Debian Stretch for this guide as my host system);
 * open a terminal emulator and get root privileges;
-* use ``fdisk -l`` in order to locate the USB key’s device file, for example: /dev/sdx (change for your case). A sample output on my PC::
+* use ``fdisk -l`` in order to locate the USB key’s device file, for example: */dev/sdx* (change for your case). A sample output on my PC::
 
     Disk /dev/sdc: 29,4 GiB, 31608274944 bytes, 61734912 sectors
     Units: sectors of 1 * 512 = 512 bytes
@@ -21,14 +21,14 @@ All the steps needed to write a standard Debian Stretch live operating system im
 * unmount the auto-mounted devices, if any (desktop environments usually have an auto-mount feature). You can see them via the ``mount`` command and unmount them by using ``umount /dev/sdxN`` for each device file;
 * finally write the image with dd; in my case the command is:: 
 
-    dd if=/home/marco/Download/debian-live-9.5.0-amd64-gnome.iso of=/dev/sdx bs=50M. 
+    dd if=/home/marco/Download/debian-live-9.5.0-amd64-gnome.iso of=/dev/sdx bs=50M
 
-Be careful or you will overwrite your hard drive content! Here I replaced /dev/sdc with /dev/sdx to avoid blind copies and pastes.
+Be careful or you will overwrite your hard drive content! Here I replaced */dev/sdc* with */dev/sdx* to avoid blind copies and pastes.
 Setting the bs command line options to 10MB (or more), speeds up the process::
 
     2365587456 bytes (2,4 GB, 2,2 GiB) copied, 31,882 s, 74,2 MB/s
 
-Please note that you must refer to the whole disk, so do not use /dev/sdx1 but /dev/sdx, as an example.
+Please note that you must refer to the whole disk, so do not use */dev/sdx1* but */dev/sdx*, as an example.
 
 Resulting partitioning scheme::
 
@@ -48,5 +48,5 @@ Being Stretch UEFI compliant and not only BIOS compatible, you will notice two p
 Your USB key can now boot your PC if set as the boot device and UEFI Secure Boot is disabled on the PC's firmware. 
 Older PCs does not have the Secure Boot feature and will boot anyway, if supported.
 
-You can now enjoy a stock Debian live operating system with the desktop environment of your choice, without any data persistence: upon booting, the (live-build modified) initd will union mount the compressed filesystem with the ram disk and pass that mount to the Linux kernel as /. Reboot the system and every data will be lost.
+You can now enjoy a stock Debian live operating system with the desktop environment of your choice, without any data persistence: upon booting, the (live-build modified) initd will union mount the compressed filesystem with the RAM disk and pass that mount to the Linux kernel as /. Reboot the system and every data will be lost.
 

docs/source/standard-live.rst

@@ -10,19 +10,19 @@ How a standard Debian live system is made
 Main components of a (Linux Debian) live operating system are:
 
 * The Linux kernel image, usually named vmlinuz. 
-* The initial RAM disk image (initrd): a RAM disk containing all the modules needed to mount the system image and some scripts and binaries to perform the task.
-* The filesystem image containing all the operating system's files (kernel and initrd as well). Usually, a SquashFS compressed filesystem is used to minimize the Debian Live image size.
-* The bootloader: a small piece of code crafted to boot from the chosen medium. It loads the Linux kernel and its initrd to run with an associated filesystem.
+* The initial RAM disk image (`initrd <https://en.wikipedia.org/wiki/Initial_ramdisk>`_): a RAM disk containing all the modules needed to mount the system image and some scripts and binaries to perform the task.
+* The filesystem image containing all the operating system's files (kernel and initrd as well). Usually, a `SquashFS <https://en.wikipedia.org/wiki/SquashFS>`_ compressed filesystem is used to minimize the Debian live image size.
+* The `bootloader <https://en.wikipedia.org/wiki/Booting>`_: a small piece of code crafted to boot from the chosen medium. It loads the Linux kernel and its initrd to run with an associated filesystem.
 
-The booting in a Debian live is a two-stage process. 
-First, the bootloader loads the kernel and initrd into memory, and passes the execution control to the kernel. 
-After some basic initializations, the kernel extracts the initramfs archive and mounts it as a temporary root filesystem. 
-The initrd contains kernel modules and userspace programs (such as the insmod tool to install kernel modules into the kernel, lvm and so on) required to initialize the physical or logical device(s) containing the real root filesystem. 
-The init script on the initrd loads modules and performs other neccessary steps, such as union-mounting the compressed filesystem image with a (possibly encrypted) persistence partition or the ram disk.
-At the end of this stage run-init deletes the initrd from memory, mounts the real root filesystem and passes control to the /sbin/init (Systemd) program on it.
+Upon booting, the computer's firmware will locate and load the first-stage bootloader, which in turn loads its second-stage, resposible for loading the kernel and the associated initrd into memory; then the bootloader passes the execution control to the kernel. 
 
-With such setup the kernel size is kept under control by allowing most of the drivers to be compiled as modules - in an initrd-less setup the drivers neccessary for the boot-time initialization of the root device must be compiled into it. 
+After some basic initializations, the kernel extracts the initrd archive and mounts it as a temporary root filesystem.
+
+The initrd contains kernel modules and userspace programs (such as the insmod tool to install kernel modules into the kernel) required to initialize the device(s) containing the real root filesystem. 
 
+The init script on the initrd loads modules and performs other neccessary steps, such as `union-mounting <https://en.wikipedia.org/wiki/Union_mount>`_ (by the use of `usunionfs <https://en.wikipedia.org/wiki/UnionFS>`_) the compressed filesystem image with a (possibly `LUKS <https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup>`_ encrypted) persistence partition or with the RAM disk.
 
+At the end of this stage the initrd is deleted from the memory, and the real root filesystem is mounted. Finally the kernel passes the control to the /sbin/init (`Systemd <https://en.wikipedia.org/wiki/Systemd>`_) program on it.
 
+With such setup the kernel size is kept under control by allowing most of the drivers to be compiled as modules - in an initrd-less setup the drivers neccessary for the boot-time initialization of the root device must be compiled into it.