* marking up device names to distinguish from surrounding text

* refactoring last paragraph or so to clarify implicit use of rescue volume
This commit is contained in:
Joe 2018-03-06 08:20:39 -05:00
parent 0cec9f1214
commit 4803d5ed3e
1 changed files with 12 additions and 11 deletions

View File

@ -1,6 +1,4 @@
OK, backing out of earlier suggestion, which was based on a misunderstanding
of the document in question:
@ -8,16 +6,16 @@ of the document in question:
The problem occurs if the reader loses track of the roles of the disk images
through the process. In **Rescue Mode**, a pile of bits goes into a volume
known temporarily as /dev/sda.
known temporarily as ```/dev/sda```.
Then, booting into the **Installer profile**, that pile of bits gets a
different name, /dev/sdb. Those bits are used to boot, but only
different name, ```/dev/sdb```. Those bits are used to boot, but only
temporarily, during installation. Unlike in **Rescue mode**, the name
/dev/sda is applied to a different volume, a volume intended to receive the
```/dev/sda``` is applied to a different volume, a volume intended to receive the
installed system and eventually to become the boot volume.
Finally, in the **Boot profile**, that pile of bits, still under the name
/dev/sda, is used to boot the system.
```/dev/sda```, is used to boot the system.
At this point, I think I'll suggest changing the language so that the two
profiles do not have the same names as the two disk images. Use of the term
@ -48,9 +46,12 @@ In the **Production** profile, one boots from the **target** image, and the **in
The process optionally can stop here, or continue into the improvements
suggested by the rest of the document.
Again, the installation necessarily entails 3 boots--into **Rescue Mode**,
into the **Installer** profile, and into the **Boot** profile
It is easier to miss the switch in the role of the disk names and volume
roles because, even though the installation necessarily entails 3
boots--into **Rescue Mode**, into the **Installer** profile, and into the
**Boot** profile--this document visually draws out the two profiles
**Installer** and **Boot** but in contrast somewhat buries the implicit
aspects of the volume used to boot in **Rescue Mode**.
roles through this process because this document visually draws out the two
profiles **Installer** and **Boot**. In contrast, it somewhat buries the
implicit aspects of the existing volume from which the system is booted into
**Rescue Mode**.