oops, left out the link. Also, kicked up the formatting and expanded on things a little
This commit is contained in:
parent
d46edcaadf
commit
bc583925fc
|
@ -1,23 +1,56 @@
|
|||
|
||||
|
||||
|
||||
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 drives because, even
|
||||
though the installation necessarily entails 3 boots--into **Rescue Mode**,
|
||||
into the **Installer** profile, and into the **Boot** profile--this document
|
||||
draws out the two profiles Installer and Boot and in contrast somewhat
|
||||
buries the implicit aspects of what is used to boot in **Rescue Mode**.
|
||||
|
||||
|
|
Loading…
Reference in New Issue