Proof reading up to line 672

This commit is contained in:
David Holland 2020-05-31 21:42:38 +02:00
parent 7156e9efd1
commit b3648a3599
Signed by: DustVoice
GPG Key ID: 47068995A14EDCA9
3 changed files with 182 additions and 147 deletions

Binary file not shown.

View File

@ -170,7 +170,7 @@ This allows you to
\texttt{AUR} & \texttt{sbupdate} \\
\end{packagetable}
You have to configure \texttt{sample-package} by editing \texttt{/etc/sample.conf}
You have to configure \texttt{sample-package}, by editing \texttt{/etc/sample.conf}
\begin{mintedlisting}
\caption*{\textit{/etc/sample.conf}}
@ -182,7 +182,7 @@ Sample.text=useful
\section{Formatting the drive}
\label{sec:formatting-the-drive}
First you probably want to get a list of all available drives, together with their corresponding device name, by issuing
First, you probably want to get a list of all available drives, together with their corresponding device name, by issuing
\begin{minted}{console}
root@archiso ~ # fdisk -l
@ -192,7 +192,7 @@ root@archiso ~ # fdisk -l
The output of \texttt{fdisk -l} is dependent on your system configuration and many other factors, like \texttt{BIOS} initialization order, etc.
\begin{CAUTION}
Don't assume the same device location between reboots!
Don't assume the same path of a device between reboots!
Always double check!
@ -207,14 +207,13 @@ In my case, the partition I want to install the root file system on is \textit{/
\textit{/dev/sdb3} will be my \texttt{swap} partition.
\begin{NOTE}
A \texttt{swap} size \textbf{twice the size of your RAM} is recommended by a lot of people.
A \texttt{swap} size twice the size of your RAM is recommended by a lot of people.
With bigger RAM sizes available today, this isnt necessary anymore.
To be exact, every distribution has different recommendations for \texttt{swap} sizes.
Also \texttt{swap} size heavily depends on whether you want to be able to hibernate, etc.
You should make the \texttt{swap} size \textbf{at least your RAM size} and for RAM sizes over \texttt{4GB} and the wish to hibernate, at least one and a half your RAM size.
\paragraph{In my opinion}
You should make the \texttt{swap} size at least your RAM size and for RAM sizes over \texttt{4GB} and the wish to hibernate, at least one and a half your RAM size.
\end{NOTE}
\begin{IMPORTANT}
@ -236,7 +235,7 @@ root@archiso ~ # mount /dev/sdb2 /mnt
\end{minted}
\begin{NOTE}
If you have an additional \texttt{EFI system partition}, because of a \emph{UEFI - GPT} setup or e.g. an existing Windows installation, which we will assume to be located under \textit{/dev/sda2} (\textit{/dev/sda} is the disk of my Windows install), youll have to \texttt{mount} this partition to the new systems \textit{/boot} folder
If you have an additional EFI System partition, because of a \emph{UEFI - GPT} setup or an existing Windows installation, for example, which we will assume to be located under \textit{/dev/sda2} (\textit{/dev/sda} is the disk of my Windows install), youll have to \texttt{mount} this partition to the new system's \textit{/boot} folder
\begin{minted}{console}
root@archiso ~ # mkdir /mnt/boot
@ -254,27 +253,27 @@ root@archiso ~ # mount /dev/sda2 /mnt/boot
\end{NOTE}
\begin{NOTE}
This setup has different partitions used for the EFI System Partition, the \texttt{root} partition, etc. than used in the rest of the guide.
This setup has different partitions, used for the EFI System partition, the \texttt{root} partition, etc., compared to the ones used in the rest of the guide.
If you want to use \texttt{grub} in conjunction with some full system encryption, you would have to adapt the disk and partition names accordingly.
The only part of the guide, which currently uses the drive/partition naming scheme used in this section is \nameref{sec:the-manual-way}.
The only part of the guide, which currently uses the drives \& partitions used in this section is \nameref{sec:the-manual-way}.
\end{NOTE}
So first we have to decide, which disk, or partition is going to hold the \texttt{luks2} encrypted \texttt{lvm2} stuff.
To start things, we first have to decide, which disk, or partition, is going to hold the \texttt{luks2} encrypted \texttt{lvm2} stuff.
In my case Im now using my NVMe SSD, with a \texttt{GPT} partition scheme, for both the EFI System Partition, in my case \textit{/dev/nvme0n1p1}, defined as a \texttt{EFI System} partition type in \texttt{fdisk}, as well as the main \texttt{LUKS} volume, in my case \textit{/dev/nvme0n1p2}, defined as a \texttt{Linux filesystem} partition type in \texttt{fdisk}.
In my case Ill be using my NVMe SSD, with a \texttt{GPT} partition scheme, for both the EFI System partition, in my case \textit{/dev/nvme0n1p1}, defined as a \texttt{EFI System} partition type in \texttt{fdisk}, as well as the main \texttt{LUKS} volume, in my case \textit{/dev/nvme0n1p2}, defined as a \texttt{Linux filesystem} partition type in \texttt{fdisk}.
After partitioning our disk, we now have to set everything up.
\subsubsection{EFI System Partition}
\subsubsection{EFI System partition}
\label{sec:efi-system-partition}
\begin{packagetable}
\texttt{core} & \texttt{dosfstools} \\
\end{packagetable}
I wont setup my EFI System Partition with \texttt{cryptsetup}, as it makes no sense in my case.
I wont setup my EFI System partition with \texttt{cryptsetup}, as it makes no sense in my case.
Every \texttt{EFI} binary (or \texttt{STUB}) has to be signed with my own \texttt{Secure Boot} keys, as described in \nameref{sec:the-manual-way}, so tempering with the EFI System Partition poses no risk to my system.
Every \texttt{EFI} binary (or \texttt{STUB}) will have to be signed with my custom Secure Boot keys, as described in \nameref{sec:the-manual-way}, so tempering with the EFI System partition poses no risk to my system.
Instead I will simply format it with a \texttt{FAT32} filesystem
@ -284,6 +283,10 @@ root@archiso ~ # mkfs.fat -F 32 -L /efi /dev/nvme0n1p1
We will bother with mounting it later on.
\begin{NOTE}
When you \textbf{do} want to encrypt your EFI System partition, in conjunction with using \texttt{grub}, please either use \texttt{LUKS 1}, or make sure to have the latest version of \texttt{grub} installed on your system, to make it work with \texttt{LUKS 2}!
\end{NOTE}
\subsubsection{\texttt{LUKS}}
\label{sec:luks}
@ -312,7 +315,7 @@ The volume is now accessible under \textit{/dev/mapper/cryptroot}.
\texttt{core} & \texttt{lvm2} \\
\end{packagetable}
Im going to create one \texttt{PV} (Physical Volume) with the just created and opened \texttt{cryptroot} \texttt{LUKS} volume, one \texttt{VG} (Volume Group), named \texttt{DustArch1}, which will contain two \texttt{LV}s (Logical Volumes) named \texttt{root} and \texttt{swap} containing the \texttt{root} filesystem and the \texttt{swap} respectively.
Im going to create one \texttt{PV} (Physical Volume) using the just created and opened \texttt{cryptroot} \texttt{LUKS} volume, one \texttt{VG} (Volume Group), named \texttt{DustArch1}, which will contain two \texttt{LV}s (Logical Volumes) named \texttt{root} and \texttt{swap} containing the \texttt{root} filesystem and the \texttt{swap} space respectively.
\begin{minted}{console}
root@archiso ~ # pvcreate /dev/mapper/cryptroot
@ -325,7 +328,7 @@ root@archiso ~ # lvcreate -L 100%FREE -n swap DustArch1
\subsubsection{Format \& mount}
\label{sec:format-and-mount}
Now the only things left to do are formatting our freshly created logical volumes
Now the only thing left to do is formatting our freshly created logical volumes appropriately
\begin{minted}{console}
root@archiso ~ # mkfs.ext4 -L / /dev/DustArch1/root
@ -346,7 +349,7 @@ root@archiso ~ # swapon /dev/DustArch1/swap
\label{sec:unmount-and-close}
\begin{WARNING}
Only do this, after youre finished with your setup within the \texttt{archiso} and are about to boot into your system, or else the next steps wont work for you.
Only do this, after youre finished with your setup within the \texttt{archiso} and are about to reboot into your new system, or else the next steps wont work for you.
\end{WARNING}
To close everything back up again,
@ -376,6 +379,34 @@ root@archiso ~ # cryptsetup close cryptroot
First it might make sense to edit \textit{/etc/pacman.d/mirrorlist} to move the mirror(s) geographically closest to you to the top.
If you're using an older version of the \texttt{archiso}, you might want to replace the mirrorlist present on the \texttt{archiso} with the newest one from \hreffn{https://archlinux.org/mirrorlist}{https://archlinux.org/mirrorlist}
\begin{minted}{console}
root@archiso ~ # curl https://archlinux.org/mirrorlist/all > /etc/pacman.d/mirrorlist
\end{minted}
\begin{NOTE}
\begin{packagetable}
\texttt{community} & \texttt{reflector} \\
\end{packagetable}
The best way to do this, is using a package from the official repositories named \texttt{reflector}.
It comes with all sorts of options, for example sorting mirrors by speed, filtering by country, etc.
\begin{minted}{console}
root@archiso ~ # reflector --verbose --latest 200 --sort rate --save /etc/pacman.d/mirrorlist
\end{minted}
After that you would need to reinstall the \texttt{pacman-mirror} package and run
\begin{minted}{console}
root@archiso ~ # pacman -Syyuu
\end{minted}
\noindent
for the best results.
\end{NOTE}
After that we can \texttt{pacstrap} the \textbf{minimum packages} needed.
We will install all other packages later on.
@ -406,15 +437,15 @@ and youre ready to enter the \texttt{chroot} environment.
\begin{NOTE}
As we want to set up our new system, we need to have access to the different partitions, the internet, etc. which we wouldnt get by solely using \texttt{chroot}.
Thats why we are using \texttt{arch-chroot}, provided by the \texttt{arch-install-scripts} package already shipped with the archiso.
This script takes care of all that stuff, so we can set up our system properly.
Thats why we are using \texttt{arch-chroot}, provided by the \texttt{arch-install-scripts} package, which is shipped with the \texttt{archiso}.
This script takes care of all the afforementioned stuff, so we can set up our system properly.
\end{NOTE}
\begin{minted}{console}
root@archiso ~ # arch-chroot /mnt
\end{minted}
Et Voil\`{a}! You successfully \texttt{chroot}ed inside your new system and youll be greeted by a \texttt{bash} prompt.
Et Voil\`{a}! You successfully \texttt{chroot}ed inside your new system and youll be greeted by a \texttt{bash} prompt, which is the default shell on fresh Arch Linux installations.
\section{Installing additional packages}
\label{sec:installing-additional-packages}
@ -428,10 +459,10 @@ Et Voil\`{a}! You successfully \texttt{chroot}ed inside your new system and you
\begin{NOTE}
There are many command line text editors available, like \texttt{nano}, \texttt{vi}, \texttt{vim}, \texttt{emacs}, etc.
Ill be using \texttt{neovim}, though it shouldnt matter what editor you choose.
Ill be using \texttt{neovim}, though it shouldnt matter what editor you choose for the rest of the guide.
\end{NOTE}
Make sure to enable the \texttt{NetworkManager.service} service, in order for the Internet connection to work upon booting into our fresh system later on.
Make sure to enable the \texttt{NetworkManager.service} service, in order for the Internet connection to work correctly, upon booting into the fresh system later on.
\begin{minted}{console}
[root@archiso /]# systemctl enable NetworkManager.service
@ -455,12 +486,12 @@ If you use \texttt{UEFI}, youll also need the \texttt{efibootmgr}, in order t
\section{Master of time}
\label{sec:master-of-time}
After that you have to set your timezone and update the system clock.
After that, you have to set your timezone and update the system clock.
Generally speaking, you can find all the different timezones under \textit{/usr/\allowbreak{}share/\allowbreak{}zoneinfo}.
In my case, my timezone resides under \textit{/usr/\allowbreak{}share/\allowbreak{}zoneinfo/\allowbreak{}Europe/\allowbreak{}Berlin}.
To achieve the desired result, I want to symlink this to \textit{/etc/localtime} and set the hardware clock.
To achieve the desired result, I will want to symlink this to \textit{/etc/localtime} and set the hardware clock.
\begin{minted}{console}
[root@archiso /]# ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime
@ -519,15 +550,14 @@ After that were done with this part.
\section{Naming your machine}
\label{sec:naming-your-machine}
Now we can set the \texttt{hostname} and add \texttt{hosts} entries.
Now we can set the \texttt{hostname} for our new install and add \texttt{hosts} entries.
Apart from being mentioned in your command prompt, the \texttt{hostname} also serves the purpose of identifying, or naming your machine.
This enables you to see your PC in your router, etc.
Apart from being mentioned in your command prompt, the \texttt{hostname} also serves the purpose of identifying, or naming your machine locally, as well as in a networked scenario. This will enable you to see your PC with the correct name in your router, etc.
\subsection{\texttt{hostname}}
\label{sec:hostname}
To change the \texttt{hostname}, simply edit \textit{/etc/hostname}, enter the desired name, then save and quit.
To change the \texttt{hostname}, simply edit \textit{/etc/hostname}, enter the desired name, then save and quit
\begin{mintedlisting}
\caption*{\textit{/etc/hostname}}
@ -616,12 +646,12 @@ dustvoice ALL=(ALL) ALL
\end{mintedlisting}
\noindent
to solely grant the new user \texttt{sudo} privileges.
to solely grant the \textbf{new} user \texttt{sudo} privileges.
\section{Boot manager}
\label{sec:boot-manager}
In this section different boot managers are explained.
In this section different boot managers / boot methods are explained.
\subsection{\texttt{EFISTUB}}
\label{sec:efistub}
@ -630,12 +660,17 @@ In this section different boot managers are explained.
\texttt{core} & \texttt{efibootmgr} \\
\end{packagetable}
You can directly load the kernel and the \texttt{initramfs} by using \texttt{efibootmgr}
You can directly boot the system, by making use of the \texttt{EFISTUB} contained in the kernel image.
To utilize this, we can use the \texttt{efibootmgr}
\begin{minted}{console}
[root@archiso /]# efibootmgr --disk /dev/sda --part 2 --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=6ff60fab-c046-47f2-848c-791fbc52df09 rw initrd=\initramfs-linux.img resume=UUID=097c6f11-f246-40eb-a702-ba83c92654f2' --verbose
\end{minted}
\begin{NOTE}
This only makes sense of course, if you're using \texttt{UEFI} instead of \texttt{BIOS}.
\end{NOTE}
\subsection{\texttt{grub}}
\label{sec:grub}
@ -680,16 +715,16 @@ In both cases youll have to \textbf{run the following comman} now
\subsubsection{\texttt{UEFI}}
\label{sec:uefi}
If you chose the \texttt{UEFI - GPT} variation, youll have to \textbf{have the EFI System Partition mounted} at \textit{/boot} (where \textit{/dev/sda2} is the partition holding said EFI System Partition in my particular setup)
If you chose the \texttt{UEFI - GPT} variation, youll have to \textbf{have the EFI System partition mounted} at \textit{/boot} (where \textit{/dev/sda2} is the partition holding said EFI System partition in my particular setup)
Now \textbf{install \texttt{grub} to the EFI System Partition}
Now \textbf{install \texttt{grub} to the EFI System partition}
\begin{minted}{console}
[root@archiso /]# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub --recheck
\end{minted}
\begin{IMPORTANT}
If youve planned on dual booting arch with Windows and therefore reused the EFI System Partition created by Windows, you might not be able to boot to grub just yet.
If youve planned on dual booting arch with Windows and therefore reused the EFI System partition created by Windows, you might not be able to boot to grub just yet.
In this case, boot into Windows, open a \texttt{cmd} window as Administrator and type in
@ -899,7 +934,7 @@ HOOKS=(base udev autodetect modconf block filesystems keyboard resume fsck)
If your motherboard doesnt support this, you would need to use \hreffn{https://wiki.archlinux.org/index.php/Systemd-boot}{\texttt{systemd-boot}}.
\end{NOTE}
\section{\texttt{Secure Boot}}
\section{Secure Boot}
\label{sec:secure-boot}
\subsection{\texttt{shim}}
@ -912,21 +947,21 @@ HOOKS=(base udev autodetect modconf block filesystems keyboard resume fsck)
\begin{WARNING}
This is a way of handling secure boot that aims at just making everything work!
It is not the way \texttt{Secure Boot} was intended to be used and you might as well disable it.
It is not the way Secure Boot was intended to be used and you might as well disable it.
If you need \texttt{Secure Boot} to be enabled, e.g. for Windows, but you couldnt care less for the security it could bring to your device, use this method.
If you need Secure Boot to be enabled, e.g. for Windows, but you couldnt care less for the security it could bring to your device, use this method.
If you want to actually make use of the \texttt{Secure Boot} feature, read \nameref{sec:the-manual-way}.
If you want to actually make use of the Secure Boot feature, read \nameref{sec:the-manual-way}.
\end{WARNING}
I know I told you that youre now good to boot into your new system.
That is only correct, if youre \textbf{not} using \texttt{Secure Boot}.
That is only correct, if youre \textbf{not} using Secure Boot.
You can either proceed by disabling \texttt{Secure Boot} in your firmware settings, or by using \texttt{shim} as kind of a pre-bootloader, as well as signing your bootloader (\texttt{grub}) and your kernel.
You can either proceed by disabling Secure Boot in your firmware settings, or by using \texttt{shim} as kind of a pre-bootloader, as well as signing your bootloader (\texttt{grub}) and your kernel.
If you decided on using \texttt{Secure Boot}, you will first have to install the package.
If you decided on using Secure Boot, you will first have to install the package.
Now we just need to copy \textit{shimx64.efi}, as well as \textit{mmx64.efi} to our EFI System Partition
Now we just need to copy \textit{shimx64.efi}, as well as \textit{mmx64.efi} to our EFI System partition
\begin{minted}{console}
[root@archiso /]# cp /usr/share/shim-signed/shimx64.efi /boot/EFI/grub/
@ -982,7 +1017,7 @@ In the following subsections, we will be dealing with some different file format
\subsubsection{Create the keys}
\label{sec:create-the-keys}
First off, we have to generate our \texttt{Secure Boot} keys.
First off, we have to generate our Secure Boot keys.
These will be used to sign any binary which will be executed by the firwmare.
@ -1063,7 +1098,7 @@ In order to ensure a smooth operation, with actual security, we need to move som
\paragraph{Kernel, \texttt{initramfs}, microcode}
\label{par:kernel-initramfs-microcode}
\texttt{pacman} will put its unsigned and unencrypted kernel, \texttt{initramfs} and microcode images into \textit{/boot}, which is, why it will be no longer a good idea, to leave your EFI System Partition mounted there.
\texttt{pacman} will put its unsigned and unencrypted kernel, \texttt{initramfs} and microcode images into \textit{/boot}, which is, why it will be no longer a good idea, to leave your EFI System partition mounted there.
Instead we will create a new mount point under \textit{/efi} and modify our \texttt{fstab} accordingly.
\paragraph{Keys}
@ -1107,7 +1142,7 @@ For example, if I want to sign the kernel image of my USB installation, where I
\texttt{AUR} & \texttt{sbupdate-git} \\
\end{packagetable}
Of course, if youre using \texttt{Secure Boot} productively, you would want something more practical than manual signing, especially since you need to sign
Of course, if youre using Secure Boot productively, you would want something more practical than manual signing, especially since you need to sign
\begin{itemize}
\item the boot loader
@ -1174,12 +1209,12 @@ Of course you can extend this list, with whichever entries you need.
\label{sec:enrolling-everything}
First off, copy all \textit{.cer}, \textit{.esl} and \textit{.auth} files to a \texttt{FAT} formatted filesystem.
Im using my EFI System Partition for this.
Im using my EFI System partition for this.
After that reboot into the firmware setup of your motherboard, clear the existing Platform Key, to set the firmware into "Setup Mode" and enroll the \texttt{db}, \texttt{KEK} and \texttt{PK} certificates in sequence.
\begin{NOTE}
Enroll the Platform Key last, as it sets most firmwares \texttt{Secure Boot} sections back into "User mode", exiting "Setup Mode".
Enroll the Platform Key last, as it sets most firmwares Secure Boot sections back into "User mode", exiting "Setup Mode".
\end{NOTE}
\chapter{Inside the \texttt{DustArch}}
@ -2968,7 +3003,7 @@ root@DustArch ~
$ mkdir /boot
\end{minted}
Now reboot and \texttt{mount} the \texttt{boot} partition, in my case an EFI System Partition.
Now reboot and \texttt{mount} the \texttt{boot} partition, in my case an EFI System partition.
Now simply rerun

Binary file not shown.