manuals: add references to the "do_rootfs" task

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
(From yocto-docs rev: 926c836e5184243fb1aee113962e11c01f0297ee)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/dev-manual/common-tasks.rst

@@ -3854,7 +3854,7 @@ to be added to the recipe that builds the ``core-image-sato`` image::
 
 In this example, the `from_multiconfig` is "x86". The `to_multiconfig` is "arm". The
 task on which the :ref:`ref-tasks-image` task in the recipe depends is the
-``do_rootfs`` task from the ``core-image-minimal`` recipe associated
+:ref:`ref-tasks-rootfs` task from the ``core-image-minimal`` recipe associated
 with the "arm" multiconfig.
 
 Once you set up this dependency, you can build the "x86" multiconfig
@@ -3864,7 +3864,7 @@ using a BitBake command as follows::
 
 This command executes all the tasks needed to create the
 ``core-image-sato`` image for the "x86" multiconfig. Because of the
-dependency, BitBake also executes through the ``do_rootfs`` task for the
+dependency, BitBake also executes through the :ref:`ref-tasks-rootfs` task for the
 "arm" multiconfig build.
 
 Having a recipe depend on the root filesystem of another build might not
@@ -9041,7 +9041,7 @@ Class methods are as follows:
 
 -  *hasPackage(pkg):* Returns "True" if ``pkg`` is in the installed
    package list of the image, which is based on the manifest file that
-   is generated during the ``do_rootfs`` task.
+   is generated during the :ref:`ref-tasks-rootfs` task.
 
 -  *hasFeature(feature):* Returns "True" if the feature is in
    :term:`IMAGE_FEATURES` or

documentation/migration-guides/migration-2.1.rst

@@ -128,12 +128,12 @@ separate :ref:`ref-tasks-image` tasks for clarity both in
 operation and in the code.
 
 For most cases, this change does not present any problems. However, if
-you have made customizations that directly modify the ``do_rootfs`` task
-or that mention ``do_rootfs``, you might need to update those changes.
-In particular, if you had added any tasks after ``do_rootfs``, you
+you have made customizations that directly modify the :ref:`ref-tasks-rootfs` task
+or that mention :ref:`ref-tasks-rootfs`, you might need to update those changes.
+In particular, if you had added any tasks after :ref:`ref-tasks-rootfs`, you
 should make edits so that those tasks are after the
 :ref:`ref-tasks-image-complete` task rather than
-after ``do_rootfs`` so that your added tasks run at the correct
+after :ref:`ref-tasks-rootfs` so that your added tasks run at the correct
 time.
 
 A minor part of this restructuring is that the post-processing

documentation/migration-guides/migration-2.5.rst

@@ -261,7 +261,7 @@ The following are additional changes:
    ``pkg_postinst_ontarget()`` or call
    ``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``.
    Any failure of a ``pkg_postinst()`` script (including ``exit 1``)
-   will trigger a warning during ``do_rootfs``.
+   will trigger a warning during :ref:`ref-tasks-rootfs`.
 
    For more information, see the
    ":ref:`dev-manual/common-tasks:post-installation scripts`"

documentation/overview-manual/concepts.rst

@@ -1012,7 +1012,7 @@ all the post installation scripts must succeed on the build host during
 the package installation phase since the root filesystem on the target
 is read-only.
 
-The final stages of the ``do_rootfs`` task handle post processing. Post
+The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post
 processing includes creation of a manifest file and optimizations.
 
 The manifest file (``.manifest``) resides in the same directory as the