Touchups to Jadi's LPIC book. Thanks for contributing to the FOSS wor…

…ld jadi :)

content/1011_determine_and_configure_hardware_settings.md

@@ -32,23 +32,23 @@ Candidates should be able to determine and configure fundamental system hardware
 
 An operating system (OS) is system software that manages computer hardware, and software resources, and provides common services for computer programs. It sits on top of the hardware and manages the resources when other software (Sometimes called an userspace program) asks for it. 
 
-Firmware is the software *on* your hardware that runs it; Think of it as a built-in os or driver for your hardware. Motherboards need some firmware to be able to work too. 
+Firmware is the software *on* your hardware that runs it; Think of it as a built-in OS or driver for your hardware. Motherboards need some firmware to be able to work too. 
 
 Firmware is a type of software that lives in hardware. Software is any program or group of programs run by a computer.
 
 ![BIOS](/images/bios.png)
-1. BIOS (Basic Input/Output System). Older, You can configure it from a text menu-based system and boot the computer from a bootloader first sector of the first partition of your hard disk (MBR). This is not enough for modern systems and most systems use a two-step boot procedure.
+1. BIOS (Basic Input/Output System). Old and redundant. It is intractable through a text menu-based system and it boots the computer by accessing the first sector of the first partition of your hard disk (MBR). This is not enough for modern systems and most systems use a two-step boot procedure.
 
 
 ![UEFI](/images/uefi.jpeg)
-2. UEFI (Unified Extensible Firmware Interface). Started as EFI in 1998 in Intel. Now the standard. Uses a specific disk partition for boot (EFI System Partition (ESP)) and uses FAT. On Linux it is on /boot/efi and files are .efi. You need to register each bootloader.
+2. UEFI (Unified Extensible Firmware Interface). Started as EFI in 1998 in Intel. Now the standard. Uses a specific disk partition for boot (EFI System Partition (ESP)) and uses FAT. On Linux it's located on `/boot/efi` and the files use the `.efi` extension. You need to register each bootloader.
 
 ![BIOSvsUEFI](/images/BIOSvsUEFI.png)
 
 ## Peripheral Devices
 These are device interfaces.
 ### PCI
-Peripheral Component Interconnect. Letting hardware boards be added to the motherboard. Now most servers use PCI Express (PCIe)
+Peripheral Component Interconnect. Enables the user to add extra components to the Motherboard. Now most servers use PCI Express (PCIe)
 
 ![PCI](/images/pci.jpeg)
 
@@ -86,12 +86,13 @@ General Purpose Input Output.
 ![GPIO on a Raspberry Pi](/images/gpio.jpeg)
 
 - To control other devices
+- Examples include Arduino, raspberrypi, etc.
 
-## sysfs
+## Sysfs
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/879oHKwgDG8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-sysfs is a pseudo file system provided by the Linux kernel that exports information about various kernel subsystems, hardware devices, and associated device drivers from the kernel's device model to user space through virtual files.[1] In addition to providing information about various devices and kernel subsystems, exported virtual files are also used for their configuration.
+Sysfs is a pseudo file system provided by the Linux kernel that exports information about various kernel subsystems, hardware devices, and associated device drivers from the kernel's device model to user space through virtual files.[1] In addition to providing information about various devices and kernel subsystems, exported virtual files are also used for their configuration.
 
 Sysfs is mounted under the `/sys` mount point.
 
@@ -281,7 +282,7 @@ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 ````
 
 ### lshw
-Shows hardware. Test it!
+Shows hardware. Might need root status to get the full list. Test it!
 
 ### lsblk
 Used for list devices that can read from or write to by blocks of data.

content/1012_boot_the_system.md

@@ -37,11 +37,11 @@ Candidates should be able to guide the system through the booting process.
 ## The Boot Process
 It is important to understand because at this stage, you have very little control over the system and you can not issue commands to troubleshoot much. You should have a good understanding of what is happening.
 
-1. Motherboard Firmware does a PowerOnSelfTest
+1. Motherboard Firmware does a PowerOnSelfTest(POST)
 2. Motherboard loads the bootloader
 3. Bootloader loads the Linux Kernel-based on its configs/commands
 4. The Kernel loads and prepares the system (root filesystem) and runs the initialization program
-5. Init program start the service, other programs, ... (web server, graphical interface, networking, etc.)
+5. Init program start the service such as web server, graphical interface, networking, etc.
 
 As we discussed in the previous section (101.1), the Firmware on the motherboard can be BIOS or UEFI. 
 
@@ -58,18 +58,18 @@ Unified Extensible Firmware Interface.
 
 - Modern and fancy
 - Specifies a special disk partition for the bootloader. Called EFI System Partition (ESP)
-- ESP is FAT and mounted on `/boot/efi` and bootloader files has .efi extensions
+- ESP is FAT and mounted on `/boot/efi` and bootloader files has `.efi` extensions
 
 > You can check `/sys/firmware/efi` to see if you are using a UEFI system or not
 
 ### Bootloader
-Bootloader initializes the minimum hardware needed to boot the system and then finds and runs the OS.
+Bootloader initializes the minimum hardware needed to boot the system. then, it locates and runs the OS.
 
-Technically you can point your UEFI to run anything you want but typically under GNU/Linux systems, we use GRUB. Even the GRUB can be used to run any specific program you need but generally it runs the OS. 
+Technically you can point your UEFI to run anything you want but typically under GNU/Linux systems, we use GRUB. GRUB can be used to run any specific program you need but it generally runs the OS. 
 
 ### Kernel
 
-The Kernel is the core of your operating system, the LINUX itself. Your bootloader loads the kernel in the memory and runs it. But kernel needs some initial info to start; Things like drivers are necessary to work with the hardware. Those are stored in `initrd` or `initramfs` alongside the kernel and used during the boot. 
+The Kernel is the core of your operating system. it basically is LINUX itself. Your bootloader loads the kernel in the memory and runs it. But the kernel needs some initial info to start; Things like drivers which are necessary to work with the hardware. Those are stored in `initrd` or `initramfs` alongside the kernel and used during the boot. 
 
 You can also send parameters to the kernel during the boot using the Grub configs. For example, sending a 1 or S will result the system booting in single-user mode (recovery). Or you can force your graphics to work in 1024×768x24 mode by passing `vga=792` to the Kernel during the boot. 
 
@@ -80,39 +80,33 @@ You can also send parameters to the kernel during the boot using the Grub config
 
 #### dmesg
 
-Linux will show you the boot process logs during the boot. Some desktop systems hide this behind a fancy boot splash which you can hide using the Esc key or press Ctrl+Alt+F1.
+Linux will show you the boot process logs during the boot. Some desktop systems hide this behind a fancy splash screen which you can hide using the `Esc` key or press `Ctrl+Alt+F1`.
 
-> **Fun Fact:** During the bootup, only The Kernel is running so it should record and keep its logs!
+due to several reasons which are beyond the scope of this course, the kernel saves it's own logs into the "Kernel Ring Buffer". after the compilation of the boot process, the syslog daemon collects the *boot logs* and stores them in `/var/log/dmesg`.
 
-dmesg command will show the full data from **kernel ring buffer** up to now. But
-
-```text
-cat /var/log/dmesg
-```
-
-will show **only** the data during the boot.
+to view all the logs including what has been logged after the boot process we use the `dmesg` command.
 
 We can also use `journalctl -k` to check Kernel logs or use `journalctl -b` to check for boot logs (or even use `journalctl -u kernel` to see all previous logs too).
 
-In addition to these, most systems keep the boot logs in a text-like file too. Under Debian-based systems, it's called `/var/log/boot` and for RedHat-based systems, it's `/var/log/boot.log`.
+In addition to these, most systems keep the boot logs in a text-like file too and they can be found in `/var/log/boot` or `/var/log/boot.log` in Debian or Red-Hat based systems, respectively.
 
 #### /var/log/messages
 
 After the init process comes up, syslog daemon will log messages. It has timestamps and will persist during restarts.
 
-* The Kernel is still logging its messages in dmesg
+* The Kernel is still logging its messages in Kernel Buffer Ring
 * in some systems, it might be called `/var/log/syslog`
 * there are many other logs at `/var/log`
 
 ## init
 
-When the Kernel finished its initialization, its time to start other programs. To do so, the Kernel runs the Initialization Daemon process, and it takes care of starting other daemons, services, subsystems and programs. Using the init system one can say "I need service A and then service B. Then I need C and D and E but do not start D unless the A and B are running". The system admin can use the init system to stop and start the services later.
+When the Kernel initialization is finished, its time to start other programs. To do so, the Kernel runs the Initialization Daemon process, and it takes care of starting other daemons, services, subsystems and programs. Using the init system one can say "I need service A and then service B. Then I need C and D and E but do not start D unless the A and B are running". The system admin can use the init system to stop and start the services later.
 
 There are different init systems:
 
-- **SysVinit** is based on Unix System V. Not being used much but people loved it and you may see it on older machines or even on recently installed ones
-- **systemd** is the new replacement. Some people hate it but it is being used by all the major distros. Can start services in parallel and do lots of fancy stuff! 
-- **upstart** was an event-based replacement for the traditional init daemon. The project was started in 2014 by Canonical (the company behind Ubuntu) to replace the SysV but did not continue after 2015 and Ubuntu is now using the systemd as its init system.
+- **SysVinit** is based on Unix System V. Not being used much anymore but people loved it because it followed Unix philosophies. you may see it on older machines or even on recently installed ones.
+- **upstart** was an event-based replacement for the traditional init daemon developed by Canonical (The people behind Ubuntu). The goal of the project was to build a replacement for SysV when it got released in 2007. eventually, the project got discontinued due to the wide adoption of Systemd. Even Ubuntu uses Systemd these days, but upstart still can be found in google's ChromeOS.
+- **Systemd** is the new replacement. It is hated by Linux elitists for not following Unix principles but it's widely adopted by major distros. It can start services in parallel and do lots of fancy stuff! 
 
 The init process had the ID of 1 and you can find it by running the 
 
@@ -135,7 +129,7 @@ pstree
 ## systemd
 Is new, loved, and hated. Lots of new ideas but not following some of the beloved UNIX principles (say.. not saving logs in a text file or trying to help you too much but asking for the root password when you are not running commands with sudo). It lets us run services if the hardware is connected, in time intervals, if another service is started, and ...
 
-The systemd is made around **unit**s. A unit can be a service, group of services, or an action. Units do have a name, a type, and a configuration file. There are 12 unit types: automount, device, mount, path, scope, service, slice, snapshot, socket, swap, target & timer.
+The systemd is made around **units**. A unit can be a service, group of services, or an action. Units do have a name, a type, and a configuration file. There are 12 unit types: automount, device, mount, path, scope, service, slice, snapshot, socket, swap, target & timer.
 
 We use `systemctl` to work with these units and `journalctl` to see the logs.