deejoe
/
bugs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

oops, left out the link. Also, kicked up the formatting and expanded on things a little

This commit is contained in:
Joe 2018-01-18 09:19:34 -05:00
parent d46edcaadf
commit 5d4e86c2f5
1 changed files with 42 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
linode-custom-install.md
View File

@ -1,23 +1,57 @@
OK, backing out of earlier suggestion, which was based on a misunderstanding
of the document in question.
of the document in question:
<https://linode.com/docs/tools-reference/custom-kernels-distros/install-a-custom-distribution-on-a-linode/#download-and-install-image>
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.
Then, booting into the **Installer profile**, that pile of bits gets a
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
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.
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.
profiles do not have the same names as the two disk images. Use of the term
**boot** to indicate a profile or a disk image either one is a problem,
since one boots a system into each of three modes: Rescue, Installer, and
the final configuration, which I suggest here be called **Production** but
could be called **Final** or something else, so long as it does not collide
with the name used for the volume that is the ultimate destination of the
installation process.
**Installation** profile, but **installer** image.
So, instead of
**Production** profile, but **target** image.
* **Installer** profile and **Installer** image
* **Boot** profile and **Boot** image
we would have
* **Installation** profile, but **installer** image.
* **Production** profile, but **target** image.
So, in Rescue Mode, one writes, eg, a GNU/Linux distribution's
download ISO file to the **installer** disk image.
When booted into the **Installation** profile, one boots from the
**installer** image, but writes to the **target** image.
When booted into the **Installation** profile, one boots from the **installer** image, but writes to the **target** image.
In the **Production** profile, one boots from the **target** image, and the
**installer** image is dormant.
In the **Production** profile, one boots from the **target** image, and the **installer** image is dormant.
The process optionally can stop here, or continue into the improvements
suggested by the rest of the document.
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**.