diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 11e0d47..5e49613 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -47,7 +47,7 @@
    even if the recipes do not produce architecture-specific output.
 
    Configuring such recipes for all architectures causes the
-   ``do_package_write_*`` tasks to
+   :ref:`do_package_write_* <ref-tasks-package_write_deb>` tasks to
    have different signatures for the machines with different tunings.
    Additionally, unnecessary rebuilds occur every time an image for a
    different :term:`MACHINE` is built even when the recipe never changes.
@@ -444,7 +444,7 @@
 ``devshell.bbclass``
 ====================
 
-The ``devshell`` class adds the ``do_devshell`` task. Distribution
+The ``devshell`` class adds the :ref:`ref-tasks-devshell` task. Distribution
 policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`"
 section in the Yocto Project Development Tasks Manual for more
 information about using ``devshell``.
@@ -1081,12 +1081,12 @@
    might result in host contamination of the build output.
 
 -  ``installed-vs-shipped:`` Reports when files have been installed
-   within ``do_install`` but have not been included in any package by
+   within :ref:`ref-tasks-install` but have not been included in any package by
    way of the :term:`FILES` variable. Files that do not
    appear in any package cannot be present in an image later on in the
    build process. Ideally, all installed files should be packaged or not
    installed at all. These files can be deleted at the end of
-   ``do_install`` if the files are not needed in any package.
+   :ref:`ref-tasks-install` if the files are not needed in any package.
 
 -  ``invalid-chars:`` Checks that the recipe metadata variables
    :term:`DESCRIPTION`,
@@ -1256,9 +1256,9 @@
 packages such as ``kernel-vmlinux``.
 
 The ``kernel`` class contains logic that allows you to embed an initial
-RAM filesystem (initramfs) image when you build the kernel image. For
-information on how to build an initramfs, see the
-":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section in
+RAM filesystem (:term:`Initramfs`) image when you build the kernel image. For
+information on how to build an :term:`Initramfs`, see the
+":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section in
 the Yocto Project Development Tasks Manual.
 
 Various other classes are used by the ``kernel`` and ``module`` classes
@@ -1339,7 +1339,7 @@
 ``kernel-fitimage`` and the boot script is optional.
 The boot script is specified in the ITS file as a text file containing
 U-boot commands. When using a boot script the user should configure the
-U-boot ``do_install`` task to copy the script to sysroot.
+U-boot :ref:`ref-tasks-install` task to copy the script to sysroot.
 So the script can be included in the FIT image by the ``kernel-fitimage``
 class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to
 load the boot script from the FIT image and executes it.
@@ -2401,7 +2401,7 @@
 
    .. note::
 
-      The ``setuptools3`` class ``do_compile()`` task now calls
+      The ``setuptools3`` class :ref:`ref-tasks-compile` task now calls
       ``setup.py bdist_wheel`` to build the ``wheel`` binary archive format
       (See `PEP-427 <https://www.python.org/dev/peps/pep-0427/>`__).
 
@@ -2412,7 +2412,7 @@
 
    .. note::
 
-     The ``setuptools3`` class ``do_install()`` task now installs the ``wheel``
+     The ``setuptools3`` class :ref:`ref-tasks-install` task now installs the ``wheel``
      binary archive. In current versions of ``setuptools`` the legacy ``setup.py
      install`` method is deprecated. If the ``setup.py`` cannot be used with
      wheels, for example it creates files outside of the Python module or
@@ -2527,7 +2527,7 @@
    want to share with other recipes that have dependencies on the
    originating recipe. Normally these dependencies are installed through
    the :ref:`ref-tasks-install` task into
-   ``${``\ :term:`D`\ ``}``. The ``do_populate_sysroot`` task
+   ``${``\ :term:`D`\ ``}``. The :ref:`ref-tasks-populate_sysroot` task
    copies a subset of these files into ``${SYSROOT_DESTDIR}``. This
    subset of files is controlled by the
    :term:`SYSROOT_DIRS`,
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 6104952..af49d57 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -54,13 +54,10 @@
 
 **Q:** Are there any products built using the OpenEmbedded build system?
 
-**A:** The software running on the `Vernier
-LabQuest <https://vernier.com/labquest/>`__ is built using the
-OpenEmbedded build system. See the `Vernier
-LabQuest <https://www.vernier.com/products/interfaces/labq/>`__ website
-for more information. There are a number of pre-production devices using
-the OpenEmbedded build system and the Yocto Project team announces them
-as soon as they are released.
+**A:** See :yocto_wiki:`Products that use the Yocto Project
+</Project_Users#Products_that_use_the_Yocto_Project>` in the Yocto Project
+Wiki. Don't hesitate to contribute to this page if you know other such
+products.
 
 **Q:** What does the OpenEmbedded build system produce as output?
 
@@ -437,7 +434,7 @@
 **Q:** The files provided by my ``*-native`` recipe do not appear to be
 available to other recipes. Files are missing from the native sysroot,
 my recipe is installing to the wrong place, or I am getting permissions
-errors during the do_install task in my recipe! What is wrong?
+errors during the :ref:`ref-tasks-install` task in my recipe! What is wrong?
 
 **A:** This situation results when a build system does not recognize the
 environment variables supplied to it by :term:`BitBake`. The
diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst
index 31fb567..4b771d0 100644
--- a/poky/documentation/ref-manual/images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -78,11 +78,11 @@
    libraries you can use in a host development environment.
 
 -  ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that
-   has the Minimal RAM-based Initial Root Filesystem (initramfs) as part
+   has the Minimal RAM-based Initial Root Filesystem (:term:`Initramfs`) as part
    of the kernel, which allows the system to find the first "init"
    program more efficiently. See the
    :term:`PACKAGE_INSTALL` variable for
-   additional information helpful when working with initramfs images.
+   additional information helpful when working with :term:`Initramfs` images.
 
 -  ``core-image-minimal-mtdutils``: A ``core-image-minimal`` image that
    has support for the Minimal MTD Utilities, which let the user
@@ -121,7 +121,7 @@
    section in the Yocto Project Development Tasks Manual.
 
 -  ``core-image-testmaster-initramfs``: A RAM-based Initial Root
-   Filesystem (initramfs) image tailored for use with the
+   Filesystem (:term:`Initramfs`) image tailored for use with the
    ``core-image-testmaster`` image.
 
 -  ``core-image-weston``: A very basic Wayland image with a terminal.
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index fbab1dc..9455bec 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -162,7 +162,7 @@
    normally expected to be empty (such as ``/tmp``). These files may
    be more appropriately installed to a different location, or
    perhaps alternatively not installed at all, usually by updating the
-   ``do_install`` task/function.
+   :ref:`ref-tasks-install` task/function.
 
 .. _qa-check-arch:
 
@@ -536,7 +536,7 @@
       in (e.g. ``FILES:${``\ :term:`PN`\ ``}`` for the main
       package).
 
-   -  Delete the files at the end of the ``do_install`` task if the
+   -  Delete the files at the end of the :ref:`ref-tasks-install` task if the
       files are not needed in any package.
 
     
@@ -582,7 +582,7 @@
    ``${datadir}/mime/packages``) and yet does not inherit the mime
    class which will ensure that these get properly installed. Either
    add ``inherit mime`` to the recipe or remove the files at the
-   ``do_install`` step if they are not needed.
+   :ref:`ref-tasks-install` step if they are not needed.
 
 
 .. _qa-check-mime-xdg:
@@ -592,7 +592,7 @@
     The specified package contains a .desktop file with a 'MimeType' key
     present, but does not inherit the mime-xdg class that is required in
     order for that to be activated. Either add ``inherit mime`` to the
-    recipe or remove the files at the ``do_install`` step if they are not
+    recipe or remove the files at the :ref:`ref-tasks-install` step if they are not
     needed.
 
 
@@ -667,8 +667,8 @@
 
     If ``usrmerge`` is in :term:`DISTRO_FEATURES`, this check will ensure that no package
     installs files to root (``/bin``, ``/sbin``, ``/lib``, ``/lib64``) directories. If you are seeing this
-    message, it indicates that the ``do_install`` step (or perhaps the build process that
-    ``do_install`` is calling into, e.g. ``make install`` is using hardcoded paths instead
+    message, it indicates that the :ref:`ref-tasks-install` step (or perhaps the build process that
+    :ref:`ref-tasks-install` is calling into, e.g. ``make install`` is using hardcoded paths instead
     of the variables set up for this (``bindir``, ``sbindir``, etc.), and should be
     changed so that it does.
 
@@ -677,7 +677,7 @@
 
 - ``Fuzz detected: <patch output> [patch-fuzz]``
 
-    This check looks for evidence of "fuzz" when applying patches within the ``do_patch``
+    This check looks for evidence of "fuzz" when applying patches within the :ref:`ref-tasks-patch`
     task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context
     lines in order to apply the patch. Consider this example:
 
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index 429f81e..533745b 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -630,7 +630,7 @@
    split into individual packages.
 
 -  ``${WORKDIR}/packages-split``: Contains the output of the
-   ``do_package`` task after the output has been split into individual
+   :ref:`ref-tasks-package` task after the output has been split into individual
    packages. There are subdirectories for each individual package created by
    the recipe.
 
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
index 62da1bf..acc97c9 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -41,6 +41,8 @@
 
 -  Ubuntu 20.04 (LTS)
 
+-  Ubuntu 22.04 (LTS)
+
 -  Fedora 34
 
 -  Fedora 35
diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index cb08a75..d4408d1 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -36,7 +36,7 @@
 
 The default behavior of this task is to run the ``oe_runmake`` function
 if a makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found.
-If no such file is found, the ``do_compile`` task does nothing.
+If no such file is found, the :ref:`ref-tasks-compile` task does nothing.
 
 .. _ref-tasks-compile_ptest_base:
 
@@ -58,7 +58,7 @@
 makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and
 :term:`CLEANBROKEN` is not set to "1". If no such
 file is found or the :term:`CLEANBROKEN` variable is set to "1", the
-``do_configure`` task does nothing.
+:ref:`ref-tasks-configure` task does nothing.
 
 .. _ref-tasks-configure_ptest_base:
 
@@ -81,7 +81,7 @@
 :ref:`deploy <ref-classes-deploy>` class and should write the output
 to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
 confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up
-``do_deploy`` as a shared state (sstate) task that can be accelerated
+:ref:`ref-tasks-deploy` as a shared state (sstate) task that can be accelerated
 through sstate use. The sstate mechanism takes care of copying the
 output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
 
@@ -90,14 +90,14 @@
    Do not write the output directly to ``${DEPLOY_DIR_IMAGE}``, as this causes
    the sstate mechanism to malfunction.
 
-The ``do_deploy`` task is not added as a task by default and
+The :ref:`ref-tasks-deploy` task is not added as a task by default and
 consequently needs to be added manually. If you want the task to run
 after :ref:`ref-tasks-compile`, you can add it by doing
 the following::
 
       addtask deploy after do_compile
 
-Adding ``do_deploy`` after other tasks works the same way.
+Adding :ref:`ref-tasks-deploy` after other tasks works the same way.
 
 .. note::
 
@@ -110,7 +110,7 @@
    See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`"
    section in the BitBake User Manual for more information.
 
-If the ``do_deploy`` task re-executes, any previous output is removed
+If the :ref:`ref-tasks-deploy` task re-executes, any previous output is removed
 (i.e. "cleaned").
 
 .. _ref-tasks-fetch:
@@ -128,15 +128,15 @@
 ``do_image``
 ------------
 
-Starts the image generation process. The ``do_image`` task runs after
+Starts the image generation process. The :ref:`ref-tasks-image` task runs after
 the OpenEmbedded build system has run the
 :ref:`ref-tasks-rootfs` task during which packages are
 identified for installation into the image and the root filesystem is
 created, complete with post-processing.
 
-The ``do_image`` task performs pre-processing on the image through the
+The :ref:`ref-tasks-image` task performs pre-processing on the image through the
 :term:`IMAGE_PREPROCESS_COMMAND` and
-dynamically generates supporting ``do_image_*`` tasks as needed.
+dynamically generates supporting :ref:`do_image_* <ref-tasks-image>` tasks as needed.
 
 For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`"
 section in the Yocto Project Overview and Concepts Manual.
@@ -146,13 +146,13 @@
 ``do_image_complete``
 ---------------------
 
-Completes the image generation process. The ``do_image_complete`` task
+Completes the image generation process. The :ref:`do_image_complete <ref-tasks-image-complete>` task
 runs after the OpenEmbedded build system has run the
 :ref:`ref-tasks-image` task during which image
-pre-processing occurs and through dynamically generated ``do_image_*``
+pre-processing occurs and through dynamically generated :ref:`do_image_* <ref-tasks-image>`
 tasks the image is constructed.
 
-The ``do_image_complete`` task performs post-processing on the image
+The :ref:`do_image_complete <ref-tasks-image-complete>` task performs post-processing on the image
 through the
 :term:`IMAGE_POSTPROCESS_COMMAND`.
 
@@ -168,9 +168,9 @@
 Copies files that are to be packaged into the holding area
 ``${``\ :term:`D`\ ``}``. This task runs with the current
 working directory set to ``${``\ :term:`B`\ ``}``, which is the
-compilation directory. The ``do_install`` task, as well as other tasks
+compilation directory. The :ref:`ref-tasks-install` task, as well as other tasks
 that either directly or indirectly depend on the installed files (e.g.
-:ref:`ref-tasks-package`, ``do_package_write_*``, and
+:ref:`ref-tasks-package`, :ref:`do_package_write_* <ref-tasks-package_write_deb>`, and
 :ref:`ref-tasks-rootfs`), run under
 :ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
 
@@ -212,7 +212,7 @@
 :term:`PACKAGES` and :term:`FILES`
 variables.
 
-The ``do_package`` task, in conjunction with the
+The :ref:`ref-tasks-package` task, in conjunction with the
 :ref:`ref-tasks-packagedata` task, also saves some
 important package metadata. For additional information, see the
 :term:`PKGDESTWORK` variable and the
@@ -327,7 +327,7 @@
        "
 
 Conversely, if you have a file whose file type is ``.patch`` or ``.diff``
-and you want to exclude it so that the ``do_patch`` task does not apply
+and you want to exclude it so that the :ref:`ref-tasks-patch` task does not apply
 it during the patch phase, you can use the "apply=no" parameter with the
 :term:`SRC_URI` statement::
 
@@ -392,7 +392,7 @@
 these variables inside your recipe if you need to make additional (or
 fewer) directories available to other recipes at build time.
 
-The ``do_populate_sysroot`` task is a shared state (sstate) task, which
+The :ref:`ref-tasks-populate_sysroot` task is a shared state (sstate) task, which
 means that the task can be accelerated through sstate use. Realize also
 that if the task is re-executed, any previous output is removed (i.e.
 "cleaned").
@@ -447,7 +447,7 @@
 ------------
 
 Removes all output files for a target from the
-:ref:`ref-tasks-unpack` task forward (i.e. ``do_unpack``,
+:ref:`ref-tasks-unpack` task forward (i.e. :ref:`ref-tasks-unpack`,
 :ref:`ref-tasks-configure`,
 :ref:`ref-tasks-compile`,
 :ref:`ref-tasks-install`, and
@@ -473,7 +473,7 @@
 Removes all output files, shared state
 (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and
 downloaded source files for a target (i.e. the contents of
-:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
+:term:`DL_DIR`). Essentially, the :ref:`ref-tasks-cleanall` task is
 identical to the :ref:`ref-tasks-cleansstate` task
 with the added removal of downloaded source files.
 
@@ -481,7 +481,7 @@
 
    $ bitbake -c cleanall recipe
 
-Typically, you would not normally use the ``cleanall`` task. Do so only
+Typically, you would not normally use the :ref:`ref-tasks-cleanall` task. Do so only
 if you want to start fresh with the :ref:`ref-tasks-fetch`
 task.
 
@@ -492,7 +492,7 @@
 
 Removes all output files and shared state
 (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a
-target. Essentially, the ``do_cleansstate`` task is identical to the
+target. Essentially, the :ref:`ref-tasks-cleansstate` task is identical to the
 :ref:`ref-tasks-clean` task with the added removal of
 shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`)
 cache.
@@ -501,13 +501,13 @@
 
    $ bitbake -c cleansstate recipe
 
-When you run the ``do_cleansstate`` task, the OpenEmbedded build system
+When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build system
 no longer uses any sstate. Consequently, building the recipe from
 scratch is guaranteed.
 
 .. note::
 
-   The ``do_cleansstate`` task cannot remove sstate from a remote sstate
+   The :ref:`ref-tasks-cleansstate` task cannot remove sstate from a remote sstate
    mirror. If you need to build a target from scratch using remote mirrors, use
    the "-f" option as follows::
 
@@ -575,10 +575,8 @@
 ``do_bundle_initramfs``
 -----------------------
 
-Combines an initial RAM disk (initramfs) image and kernel together to
-form a single image. The
-:term:`CONFIG_INITRAMFS_SOURCE` variable
-has some more information about these types of images.
+Combines an :term:`Initramfs` image and kernel together to
+form a single image.
 
 .. _ref-tasks-rootfs:
 
@@ -657,7 +655,7 @@
 
 Converts the newly unpacked kernel source into a form with which the
 OpenEmbedded build system can work. Because the kernel source can be
-fetched in several different ways, the ``do_kernel_checkout`` task makes
+fetched in several different ways, the :ref:`ref-tasks-kernel_checkout` task makes
 sure that subsequent tasks are given a clean working tree copy of the
 kernel with the correct branches checked out.
 
@@ -668,7 +666,7 @@
 
 Validates the configuration produced by the
 :ref:`ref-tasks-kernel_menuconfig` task. The
-``do_kernel_configcheck`` task produces warnings when a requested
+:ref:`ref-tasks-kernel_configcheck` task produces warnings when a requested
 configuration does not appear in the final ``.config`` file or when you
 override a policy configuration in a hardware configuration fragment.
 You can run this task explicitly and view the output by using the
@@ -686,7 +684,7 @@
 ----------------------
 
 After the kernel is patched by the :ref:`ref-tasks-patch`
-task, the ``do_kernel_configme`` task assembles and merges all the
+task, the :ref:`ref-tasks-kernel_configme` task assembles and merges all the
 kernel config fragments into a merged configuration that can then be
 passed to the kernel configuration phase proper. This is also the time
 during which user-specified defconfigs are applied if present, and where
@@ -719,7 +717,7 @@
 
 Collects all the features required for a given kernel build, whether the
 features come from :term:`SRC_URI` or from Git
-repositories. After collection, the ``do_kernel_metadata`` task
+repositories. After collection, the :ref:`ref-tasks-kernel_metadata` task
 processes the features into a series of config fragments and patches,
 which can then be applied by subsequent tasks such as
 :ref:`ref-tasks-patch` and
@@ -791,4 +789,4 @@
 sure that the machine and metadata branches as specified by the
 :term:`SRCREV` variables actually exist on the specified
 branches. Otherwise, if :term:`AUTOREV` is not being used, the
-``do_validate_branches`` task fails during the build.
+:ref:`ref-tasks-validate_branches` task fails during the build.
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 2971654..1685a26 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -1242,24 +1242,24 @@
          :term:`Source Directory`.
 
    :term:`CONFIG_INITRAMFS_SOURCE`
-      Identifies the initial RAM filesystem (initramfs) source files. The
+      Identifies the initial RAM filesystem (:term:`Initramfs`) source files. The
       OpenEmbedded build system receives and uses this kernel Kconfig
       variable as an environment variable. By default, the variable is set
       to null ("").
 
       The :term:`CONFIG_INITRAMFS_SOURCE` can be either a single cpio archive
       with a ``.cpio`` suffix or a space-separated list of directories and
-      files for building the initramfs image. A cpio archive should contain
-      a filesystem archive to be used as an initramfs image. Directories
-      should contain a filesystem layout to be included in the initramfs
+      files for building the :term:`Initramfs` image. A cpio archive should contain
+      a filesystem archive to be used as an :term:`Initramfs` image. Directories
+      should contain a filesystem layout to be included in the :term:`Initramfs`
       image. Files should contain entries according to the format described
       by the ``usr/gen_init_cpio`` program in the kernel tree.
 
-      If you specify multiple directories and files, the initramfs image
+      If you specify multiple directories and files, the :term:`Initramfs` image
       will be the aggregate of all of them.
 
-      For information on creating an initramfs, see the
-      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      For information on creating an :term:`Initramfs`, see the
+      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`CONFIG_SITE`
@@ -1620,7 +1620,7 @@
       the appropriate staging sysroot, given by the
       :term:`STAGING_DIR* <STAGING_DIR>` variables, by the time the
       :ref:`ref-tasks-configure` task for ``foo`` runs.
-      This mechanism is implemented by having ``do_configure`` depend on
+      This mechanism is implemented by having :ref:`ref-tasks-configure` depend on
       the :ref:`ref-tasks-populate_sysroot` task of
       each recipe listed in :term:`DEPENDS`, through a
       ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
@@ -3182,10 +3182,10 @@
             image, do not use the :term:`IMAGE_INSTALL` variable to specify
             packages for installation. Instead, use the
             :term:`PACKAGE_INSTALL` variable, which
-            allows the initial RAM filesystem (initramfs) recipe to use a
+            allows the initial RAM filesystem (:term:`Initramfs`) recipe to use a
             fixed set of packages and not be affected by :term:`IMAGE_INSTALL`.
-            For information on creating an initramfs, see the
-            ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
+            For information on creating an :term:`Initramfs`, see the
+            ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`"
             section in the Yocto Project Development Tasks Manual.
 
          -  Using :term:`IMAGE_INSTALL` with the
@@ -3265,7 +3265,7 @@
       to distinguish the image file from other files created during image
       building; however if this suffix is redundant or not desired you can
       clear the value of this variable (set the value to ""). For example,
-      this is typically cleared in initramfs image recipes.
+      this is typically cleared in :term:`Initramfs` image recipes.
 
    :term:`IMAGE_OVERHEAD_FACTOR`
       Defines a multiplier that the build system applies to the initial
@@ -3632,37 +3632,79 @@
          even if the toolchain's binaries are strippable, there are other files
          needed for the build that are not strippable.
 
+   :term:`Initramfs`
+      An Initial RAM Filesystem (:term:`Initramfs`) is an optionally compressed
+      `cpio <https://en.wikipedia.org/wiki/Cpio>`__ archive which is extracted
+      by the Linux kernel into RAM in a special `tmpfs <https://en.wikipedia.org/wiki/Tmpfs>`__
+      instance, used as the initial root filesystem.
+
+      This is a replacement for the legacy init RAM disk ("initrd")
+      technique, booting on an emulated block device in RAM, but being less
+      efficient because of the overhead of going through a filesystem and
+      having to duplicate accessed file contents in the file cache in RAM,
+      as for any block device.
+
+      .. note:
+
+         As far as bootloaders are concerned, :term:`Initramfs` and "initrd"
+         images are still copied to RAM in the same way. That's why most
+	 most bootloaders refer to :term:`Initramfs` images as "initrd"
+	 or "init RAM disk".
+
+      This kind of mechanism is typically used for two reasons:
+
+      -  For booting the same kernel binary on multiple systems requiring
+         different device drivers. The Initramfs image is then customized
+	 for each type of system, to include the specific  kernel modules
+         necessary to access the final root filesystem. This technique
+	 is used on all GNU / Linux distributions for desktops and servers.
+
+      -  For booting faster. As the root filesystem is extracted into RAM,
+         accessing the first user-space applications is very fast, compared
+         to having to initialize a block device, to access multiple blocks
+         from it, and to go through a filesystem having its own overhead.
+         For example, this allows to display a splashscreen very early,
+	 and to later take care of mounting the final root filesystem and
+         loading less time-critical kernel drivers.
+
+      This cpio archive can either be loaded to RAM by the bootloader,
+      or be included in the kernel binary.
+
+      For information on creating and using an :term:`Initramfs`, see the
+      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`"
+      section in the Yocto Project Development Tasks Manual.
+
    :term:`INITRAMFS_DEPLOY_DIR_IMAGE`
-      Indicates the deploy directory used by ``do_bundle_initramfs`` where the
+      Indicates the deploy directory used by :ref:`ref-tasks-bundle_initramfs` where the
       :term:`INITRAMFS_IMAGE` will be fetched from.
       This variable is set by default to ``${DEPLOY_DIR_IMAGE}`` in the
       :ref:`kernel <ref-classes-kernel>` class and it's only meant to be changed
-      when building an initramfs image from a separate multiconfig via :term:`INITRAMFS_MULTICONFIG`.
+      when building an :term:`Initramfs` image from a separate multiconfig via :term:`INITRAMFS_MULTICONFIG`.
 
    :term:`INITRAMFS_FSTYPES`
       Defines the format for the output image of an initial RAM filesystem
-      (initramfs), which is used during boot. Supported formats are the
+      (:term:`Initramfs`), which is used during boot. Supported formats are the
       same as those supported by the
       :term:`IMAGE_FSTYPES` variable.
 
       The default value of this variable, which is set in the
       ``meta/conf/bitbake.conf`` configuration file in the
       :term:`Source Directory`, is "cpio.gz". The Linux kernel's
-      initramfs mechanism, as opposed to the initial RAM filesystem
+      :term:`Initramfs` mechanism, as opposed to the initial RAM filesystem
       `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
       an optionally compressed cpio archive.
 
    :term:`INITRAMFS_IMAGE`
       Specifies the :term:`PROVIDES` name of an image
-      recipe that is used to build an initial RAM filesystem (initramfs)
+      recipe that is used to build an initial RAM filesystem (:term:`Initramfs`)
       image. In other words, the :term:`INITRAMFS_IMAGE` variable causes an
       additional recipe to be built as a dependency to whatever root
       filesystem recipe you might be using (e.g. ``core-image-sato``). The
-      initramfs image recipe you provide should set
+      :term:`Initramfs` image recipe you provide should set
       :term:`IMAGE_FSTYPES` to
       :term:`INITRAMFS_FSTYPES`.
 
-      An initramfs image provides a temporary root filesystem used for
+      An :term:`Initramfs` image provides a temporary root filesystem used for
       early system initialization (e.g. loading of modules needed to locate
       and mount the "real" root filesystem).
 
@@ -3670,8 +3712,8 @@
 
          See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
          recipe in the :term:`Source Directory`
-         for an example initramfs recipe. To select this sample recipe as
-         the one built to provide the initramfs image, set :term:`INITRAMFS_IMAGE`
+         for an example :term:`Initramfs` recipe. To select this sample recipe as
+         the one built to provide the :term:`Initramfs` image, set :term:`INITRAMFS_IMAGE`
          to "core-image-minimal-initramfs".
 
       You can also find more information by referencing the
@@ -3681,13 +3723,13 @@
       class to see how to use the :term:`INITRAMFS_IMAGE` variable.
 
       If :term:`INITRAMFS_IMAGE` is empty, which is the default, then no
-      initramfs image is built.
+      :term:`Initramfs` image is built.
 
       For more information, you can also see the
       :term:`INITRAMFS_IMAGE_BUNDLE`
       variable, which allows the generated image to be bundled inside the
-      kernel image. Additionally, for information on creating an initramfs
-      image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      kernel image. Additionally, for information on creating an :term:`Initramfs`
+      image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`INITRAMFS_IMAGE_BUNDLE`
@@ -3696,32 +3738,32 @@
       extra pass
       (:ref:`ref-tasks-bundle_initramfs`) during
       kernel compilation in order to build a single binary that contains
-      both the kernel image and the initial RAM filesystem (initramfs)
+      both the kernel image and the initial RAM filesystem (:term:`Initramfs`)
       image. This makes use of the
       :term:`CONFIG_INITRAMFS_SOURCE` kernel
       feature.
 
       .. note::
 
-         Bundling the initramfs with the kernel conflates the code in the
-         initramfs with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
-         compatible software may be part of a bundled initramfs.
+         Bundling the :term:`Initramfs` with the kernel conflates the code in the
+         :term:`Initramfs` with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
+         compatible software may be part of a bundled :term:`Initramfs`.
 
       .. note::
 
-         Using an extra compilation pass to bundle the initramfs avoids a
-         circular dependency between the kernel recipe and the initramfs
-         recipe should the initramfs include kernel modules. Should that be
-         the case, the initramfs recipe depends on the kernel for the
-         kernel modules, and the kernel depends on the initramfs recipe
-         since the initramfs is bundled inside the kernel image.
+         Using an extra compilation pass to bundle the :term:`Initramfs` avoids a
+         circular dependency between the kernel recipe and the :term:`Initramfs`
+         recipe should the :term:`Initramfs` include kernel modules. Should that be
+         the case, the :term:`Initramfs` recipe depends on the kernel for the
+         kernel modules, and the kernel depends on the :term:`Initramfs` recipe
+         since the :term:`Initramfs` is bundled inside the kernel image.
 
       The combined binary is deposited into the ``tmp/deploy`` directory,
       which is part of the :term:`Build Directory`.
 
       Setting the variable to "1" in a configuration file causes the
       OpenEmbedded build system to generate a kernel image with the
-      initramfs specified in :term:`INITRAMFS_IMAGE` bundled within::
+      :term:`Initramfs` specified in :term:`INITRAMFS_IMAGE` bundled within::
 
          INITRAMFS_IMAGE_BUNDLE = "1"
 
@@ -3739,7 +3781,7 @@
       See the
       :yocto_git:`local.conf.sample.extended </poky/tree/meta-poky/conf/templates/default/local.conf.sample.extended>`
       file for additional information. Also, for information on creating an
-      initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      :term:`Initramfs`, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`INITRAMFS_LINK_NAME`
@@ -3764,7 +3806,7 @@
       This allows the kernel to bundle an :term:`INITRAMFS_IMAGE` coming from
       a separate multiconfig, this is meant to be used in addition to :term:`INITRAMFS_DEPLOY_DIR_IMAGE`.
 
-      For more information on how to bundle an initramfs image from a separate
+      For more information on how to bundle an :term:`Initramfs` image from a separate
       multiconfig see the ":ref:`dev-manual/common-tasks:Bundling an Initramfs Image From a Separate Multiconfig`"
       section in the Yocto Project Development Tasks Manual.
 
@@ -4240,7 +4282,7 @@
       :term:`KERNELDEPMODDEPEND` does not control whether or not that data
       exists, but simply whether or not it is used. If you do not need to
       use the data, set the :term:`KERNELDEPMODDEPEND` variable in your
-      ``initramfs`` recipe. Setting the variable there when the data is not
+      :term:`Initramfs` recipe. Setting the variable there when the data is not
       needed avoids a potential dependency loop.
 
    :term:`KFEATURE_DESCRIPTION`
@@ -5395,9 +5437,9 @@
       :term:`IMAGE_INSTALL` variable to specify
       packages for installation. The exception to this is when working with
       the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
-      image. When working with an initial RAM filesystem (initramfs) image,
+      image. When working with an initial RAM filesystem (:term:`Initramfs`) image,
       use the :term:`PACKAGE_INSTALL` variable. For information on creating an
-      initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      :term:`Initramfs`, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGE_INSTALL_ATTEMPTONLY`
@@ -5521,7 +5563,7 @@
       :ref:`cmake <ref-classes-cmake>` use :term:`PACKAGECONFIG_CONFARGS` to
       pass :term:`PACKAGECONFIG` options to ``configure`` and ``cmake``,
       respectively. If you are using :term:`PACKAGECONFIG` but not a class that
-      handles the ``do_configure`` task, then you need to use
+      handles the :ref:`ref-tasks-configure` task, then you need to use
       :term:`PACKAGECONFIG_CONFARGS` appropriately.
 
    :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY`
@@ -5603,7 +5645,7 @@
       .. note::
 
          If the software being built experiences dependency issues during
-         the ``do_compile`` task that result in race conditions, you can clear
+         the :ref:`ref-tasks-compile` task that result in race conditions, you can clear
          the :term:`PARALLEL_MAKE` variable within the recipe as a workaround. For
          information on addressing race conditions, see the
          ":ref:`dev-manual/common-tasks:debugging parallel make races`"
@@ -5633,7 +5675,7 @@
          way to ensure this is to use the ``oe_runmake`` function.
 
          If the software being built experiences dependency issues during
-         the ``do_install`` task that result in race conditions, you can
+         the :ref:`ref-tasks-install` task that result in race conditions, you can
          clear the :term:`PARALLEL_MAKEINST` variable within the recipe as a
          workaround. For information on addressing race conditions, see the
          ":ref:`dev-manual/common-tasks:debugging parallel make races`"
@@ -6200,7 +6242,7 @@
       The practical effect of the above :term:`RDEPENDS` assignment is that
       ``bar`` and ``baz`` will be declared as dependencies inside the
       package ``foo`` when it is written out by one of the
-      :ref:`do_package_write_\* <ref-tasks-package_write_deb>` tasks.
+      :ref:`do_package_write_* <ref-tasks-package_write_deb>` tasks.
       Exactly how this is done depends on which package format is used,
       which is determined by
       :term:`PACKAGE_CLASSES`. When the
@@ -6212,7 +6254,7 @@
       added. This dependency is from the recipe's
       :ref:`ref-tasks-build` (not to be confused with
       :ref:`ref-tasks-compile`) task to the
-      ``do_package_write_*`` task of the recipes that build ``bar`` and
+      :ref:`do_package_write_* <ref-tasks-package_write_deb>` task of the recipes that build ``bar`` and
       ``baz``.
 
       The names of the packages you list within :term:`RDEPENDS` must be the
@@ -6709,10 +6751,10 @@
       A list of shared state tasks added to the extensible SDK. By default,
       the following tasks are added:
 
-      - do_populate_lic
-      - do_package_qa
-      - do_populate_sysroot
-      - do_deploy
+      - :ref:`ref-tasks-populate_lic`
+      - :ref:`ref-tasks-package_qa`
+      - :ref:`ref-tasks-populate_sysroot`
+      - :ref:`ref-tasks-deploy`
 
       Despite the default value of "" for the
       :term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
@@ -7382,7 +7424,7 @@
       For most recipes, this sysroot is the one in which that recipe's
       :ref:`ref-tasks-populate_sysroot` task copies
       files. Exceptions include ``-native`` recipes, where the
-      ``do_populate_sysroot`` task instead uses
+      :ref:`ref-tasks-populate_sysroot` task instead uses
       :term:`STAGING_DIR_NATIVE`. Depending on
       the type of recipe and the build target, :term:`STAGING_DIR_HOST` can
       have the following values: