@@ -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
@@ -9081,7 +9081,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
@@ -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
@@ -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`"
@@ -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