The original purpose of this code snippet was to repackage initramfs
bundled kernel images before do_image_complete, to be able to be
included by rootfs, but it's not going to achieve that since the
initramfs bundled kernel images are not even installed to ${D}/boot
after commit a49569e3a7534779bbe3f01a0647fd076c95798d:
[ kernel.bbclass: do not copy bundled initramfs to /boot ]
So there is not a initramfs bundled kernel package at all, we should
drop the code, because it is leading kernel do_initramfs_bundle
unnecessarily rerun and it's very time consuming and hence is impacting
the performance a lot.
(From OE-Core master rev: eca501aeb4f2cc9255fabab14c68f6910367aaf9)
(From OE-Core rev: 22fd010b71b6ce79f3ede31e4e7da9dbc72de70e)
(From OE-Core rev: f549338b0ed4d53dedac84c86e70ea9ffd12a17e)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the introduction of chaining compression/conversion support we can
convert the old image_types_uboot.bbclass code that did a hand-chaining
of a set of ${filesystem}.${compression} into generic and arbitrary
support to sign whatever the user wants to sign for their image.
This, for the record, does remove setting a valid compression type in
the record in favour of just saying none. This is not a generally
useful feature in U-Boot and I believe being versatile in terms of being
able to pass in arbitrary compressions is more important.
(From OE-Core rev: 979ff606d8c4c6f66c6dc533a92212f18708089e)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When selected multiple subimages a similar error could happend:
Variable do_image_cpio[subimages] value changed \
from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot'
To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'.
This garantee that 'CONVERSION_CMD_xxx' are always written in tha same
order and consequently 'do_image_cpio' have the same hash.
(From OE-Core rev: 271f1a5f65b8685a1e3645026876251122ef3974)
(From OE-Core rev: 404a04a862a71a5a0fb1c20b6bc9fc9c8b2bb98c)
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we have more than one CONVERSION_CMD being used, for example
ext4.gz.sha256sum we will see errors about "metadata is not
deterministic". This is because we do not have a stable order of
intermediate files that will be removed in the generated shell command.
We fix this by calling sorted() on the set of rm_tmp_images so that we
will have a stable hash again.
Cc: Patrick Ohly <patrick.ohly@intel.com>
(From OE-Core rev: 26feb0580642ef8934206ea73cdce9e1f73d14ef)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When chaining of compression/conversion types was added, we had a new
way to handle doing things like "ext4.bz2.sha256sum" or
"ext2.gz.u-boot". However, because the U-Boot image class isn't
included normally, it wasn't properly converted at the time. After the
support was added the "clean" argument that the .u-boot code uses no
longer functions. The fix for this inadvertently broke chaining
compression/conversion. First, correct the u-boot conversion code.
Fixes: 46bc438374de ("image.bbclass: do exact match for rootfs type")
Cc: Zhenhua Luo <zhenhua.luo@nxp.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Patrick Ohly <patrick.ohly@intel.com>
(From OE-Core rev: ad22f73519292f53d2ea6eaae99f8a919c4f2c26)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The logic is scattered all over the place, but amounts to
"install, unless the rootfs is read only". Let's express that directly.
(From OE-Core rev: 697804229a172125ce7d3bfc9b343812d6fe3240)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "container" fstype does very little other than pick tar.bz2 as the
actual image type and disable installation of ROOTFS_BOOTSTRAP_INSTALL.
[YOCTO #9502]
(From OE-Core rev: e45f074b792a43aa2fd84a5a3f0e20bf1d88ad7e)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When 'populate_sdk_ext' was first introduced in commit bf81d6bb7f6 it
replaced the inheriting of 'populate_sdk_base'. For non-linux targets
building the extensible SDK caused build errors, and the image class was
changed to inherit 'populate_sdk' when targeting a non-linux SDK_OS (in
commmit e471ce3464d). However inheriting 'populate_sdk' instead of
'populate_sdk_base' causes the SDK to always be built, this is not
expected for the image class.
This change makes the image class inherit 'populate_sdk_base' in the
non-linux SDK_OS case so that it behaves the same as it is expected to
behave where 'bitbake <image> -c populate_sdk' must be executed to
generate the SDK deployables.
(From OE-Core rev: b7d6bb07fd37c55d07903a1e8921f17e39afde0a)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that the datastore works dynamically we don't need the update_data calls
so we can just remove them. They're not actually done anything at all for
a while.
(From OE-Core rev: 8de0c5d3bd01919e2bf0394f9c485936d6098cec)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make name of the wic image type class consistent with
existing naming scheme for image types.
(From OE-Core rev: 4aab1b77d5f9403cbb3fae790069ef54821491fb)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a lot of wic code in image.bbclass and image_types.bbclass
Having all code separated in one file should make it more readable
and easier to maintain.
(From OE-Core rev: 786368568a9525212e69f5cbf6da236f0a6be013)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current location of .env files $STAGING_DIR/imagedata. It doesn't
depend on machine and be rewritten by the builds for different
machines.
Changed location to $STAGING_DIR/$MACHINE/imagedata to avoid .env
files to be rewritten.
(From OE-Core rev: 94245144f5cef344d90bc2a7b3267cdae9d192e4)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With recipe specific sysroots, the gzip-replacement-native dance/class
is obsolete, simplify the code accordingly.
(From OE-Core rev: 39865fdf3698a130f792d41853f9c9ca1901e335)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We used to have issues removing tasks like do_fetch due to implications
for targets like world and universe. These have now been resolved.
Removing uneeded tasks has advantages compared to noexec since it means
that accidentally left in dependencies are no longer needed/processed
(e.g. do_patch depends on quilt-native).
This cleans up a number of cases which local analysis highlighted as
being unneeded leading to slightly cleaner task graphs.
(From OE-Core rev: 4e6ee37e09c60e83c0dfd844ba9cf8a07507f099)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting do_populate_sysroot as noexec means the code keeps thinking it can find
a manifest file for it. It also complicates sstate installtion since the code
would believe there is an sstate object there it should look for.
Instead, delete the task. This causes sdk failures as the dependencies are wrong
so fix those as well.
(From OE-Core rev: bd7d0314038a4c1a8e8c9ebdb7194f8e17db3fef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As STAGING_DIR_TARGET started to point to a recipe specific
sysroot wic is not able to add .env files when .wks file refers
to multiple rootfs recipes.
Used STAGING_DIR instead of STAGING_DIR_TARGET to make the
directory with .env files the same for all recipes.
(From OE-Core rev: 3797cfd7473d3f9b7c0d999dcf9cd9608c8c7c6c)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch is comparatively large and invasive. It does only do one thing, switching the
system to build using recipe specific sysroots and where changes could be isolated from it,
that has been done.
With the current single sysroot approach, its possible for software to find things which
aren't in their dependencies. This leads to a determinism problem and is a growing issue in
several of the market segments where OE makes sense. The way to solve this problem for OE is
to have seperate sysroots for each recipe and these will only contain the dependencies for
that recipe.
Its worth noting that this is not task specific sysroots and that OE's dependencies do vary
enormously by task. This did result in some implementation challenges. There is nothing stopping
the implementation of task specific sysroots at some later point based on this work but
that as deemed a bridge too far right now.
Implementation details:
* Rather than installing the sysroot artefacts into a combined sysroots, they are now placed in
TMPDIR/sysroot-components/PACKAGE_ARCH/PN.
* WORKDIR/recipe-sysroot and WORKDIR/recipe-sysroot-native are built by hardlinking in files
from the sysroot-component trees. These new directories are known as RECIPE_SYSROOT and
RECIPE_SYSROOT_NATIVE.
* This construction is primarily done by a new do_prepare_recipe_sysroot task which runs
before do_configure and consists of a call to the extend_recipe_sysroot function.
* Other tasks need things in the sysroot before/after this, e.g. do_patch needs quilt-native
and do_package_write_deb needs dpkg-native. The code therefore inspects the dependencies
for each task and adds extend_recipe_sysroot as a prefunc if it has populate_sysroot
dependencies.
* We have to do a search/replace 'fixme' operation on the files installed into the sysroot to
change hardcoded paths into the correct ones. We create a fixmepath file in the component
directory which lists the files which need this operation.
* Some files have "postinstall" commands which need to run against them, e.g. gdk-pixbuf each
time a new loader is added. These are handled by adding files in bindir with the name
prefixed by "postinst-" and are run in each sysroot as its created if they're present.
This did mean most sstate postinstalls have to be rewritten but there shouldn't be many of them.
* Since a recipe can have multiple tasks and these tasks can run against each other at the same
time we have to have a lock when we perform write operations against the sysroot. We also have
to maintain manifests of what we install against a task checksum of the dependency. If the
checksum changes, we remove its files and then add the new ones.
* The autotools logic for filtering the view of m4 files is no longer needed (and was the model
for the way extend_recipe_sysroot works).
* For autotools, we used to build a combined m4 macros directory which had both the native and
target m4 files. We can no longer do this so we use the target sysroot as the default and add
the native sysroot as an extra backup include path. If we don't do this, we'd have to build
target pkg-config before we could built anything using pkg-config for example (ditto gettext).
Such dependencies would be painful so we haven't required that.
* PKDDATA_DIR was moved out the sysroot and works as before using sstate to build a hybrid copy
for each machine. The paths therefore changed, the behaviour did not.
* The ccache class had to be reworked to function with rss.
* The TCBOOTSTRAP sysroot for compiler bootstrap is no longer needed but the -initial data
does have to be filtered out from the main recipe sysroots. Putting "-initial" in a normal
recipe name therefore remains a bad idea.
* The logic in insane needed tweaks to deal with the new path layout, as did the debug source
file extraction code in package.bbclass.
* The logic in sstate.bbclass had to be rewritten since it previously only performed search and
replace on extracted sstate and we now need this to happen even if the compiled path was
"correct". This in theory could cause a mild performance issue but since the sysroot data
was the main data that needed this and we'd have to do it there regardless with rss, I've opted
just to change the way the class for everything. The built output used to build the sstate output
is now retained and installed rather than deleted.
* The search and replace logic used in sstate objects also seemed weak/incorrect and didn't hold
up against testing. This has been rewritten too. There are some assumptions made about paths, we
save the 'proper' search and replace operations to fixmepath.cmd but then ignore this. What is
here works but is a little hardcoded and an area for future improvement.
* In order to work with eSDK we need a way to build something that looks like the old style sysroot.
"bitbake build-sysroots" will construct such a sysroot based on everything in the components
directory that matches the current MACHINE. It will allow transition of external tools and can
built target or native variants or both. It also supports a clean task. I'd suggest not relying on
this for anything other than transitional purposes though. To see XXX in that sysroot, you'd have
to have built that in a previous bitbake invocation.
* pseudo is run out of its components directory. This is fine as its statically linked.
* The hacks for wayland to see allarch dependencies in the multilib case are no longer needed
and can be dropped.
* wic needed more extensive changes to work with rss and the fixes are in a separate commit series
* Various oe-selftest tweaks were needed since tests did assume the location to binaries and the
combined sysroot in several cases.
* Most missing dependencies this work found have been sent out as separate patches as they were found
but a few tweaks are still included here.
* A late addition is that extend_recipe_sysroot became multilib aware and able to populate multilib
sysroots. I had hoped not to have to add that complexity but the meta-environment recipe forced my
hand. That implementation can probably be neater but this is on the list of things to cleanup later
at this point.
In summary, the impact people will likely see after this change:
* Recipes may fail with missing dependencies, particularly native tools like gettext-native,
glib-2.0-native and libxml2.0-native. Some hosts have these installed and will mask these errors
* Any recipe/class using SSTATEPOSTINSTFUNCS will need that code rewriting into a postinst
* There was a separate patch series dealing with roots postinst native dependency issues. Any postinst
which expects native tools at rootfs time will need to mark that dependency with PACKAGE_WRITE_DEPS.
There could well be other issues. This has been tested repeatedly against our autobuilders and oe-selftest
and issues found have been fixed. We believe at least OE-Core is in good shape but that doesn't mean
we've found all the issues.
Also, the logging is a bit chatty at the moment. It does help if something goes wrong and goes to the
task logfiles, not the console so I've intentionally left this like that for now. We can turn it down
easily enough in due course.
(From OE-Core rev: 809746f56df4b91af014bf6a3f28997d6698ac78)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The staging code strips binaries and we need virtual/binutils for that.
Add a specific dependency since the one from do_configure and others
may not be enough to ensure the binaries are in our own sysroot.
(From OE-Core rev: 9a799f70574ee8e0b1267497edfb4ac63166ef8f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.
Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)
(From OE-Core rev: 2dea9e490a98377010b3d4118d054814c317a735)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you printed a warning through bb.warn() / bbwarn or an error through
bb.error() / bberror, this was also being picked up by our log_check
mechanism that was designed to pick up warnings and errors printed by
other programs used during do_rootfs. This meant you saw not only the
warning or error itself, you saw it a second time through log_check,
which is a bit ugly. Use the just-added BB_TASK_LOGGER to access the
logger and add a handler that we can use to find out if any warning or
error we find in the logs is one we should ignore as it has already been
printed.
Fixes [YOCTO #8223].
(From OE-Core rev: fb37304d27857df3c53c0867e81fbc8899b48089)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
MACHINE = "qemuarm"
IMAGE_FSTYPES += "ext3.bz2.u-boot"
[snip]
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'ext3.bz2.u-boot' - possibly invalid type name or missing support class
[snip]
This is because image_types_uboot is not inherited, inherit it when
needed will fix the problem.
(From OE-Core rev: 742a22ab7fd333e99d8701220d5a1db28347b1af)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the move to put image deployment under sstate control in
d54339d4b1a7e884de636f6325ca60409ebd95ff old images are automatically
removed before a new image is deployed (the default behaviour of the
sstate logic).
RM_OLD_IMAGE is therefore no longer required to provide this
behaviour, remove the variable and its users.
(From OE-Core rev: 93631befe8b962bf99524746b49f4ebca336175c)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
IMAGE_DEVICE_TABLE and IMAGE_DEVICE_TABLES are both referenced by
_create_devfs, therefore ensure that rootfs is rebuilt if changes
are made to either variable.
(From OE-Core rev: 06092cee0dc8c7cd2408ddfa9e9dc43fd9dfea2e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When IMAGE_GEN_DEBUGFS is enabled, and IMAGE_FSTYPES_DEBUGFS is left
at its default (as suggested by local.conf.sample.extended),
recipe parsing fails:
bitbake kern-tools-native # or anything else for that matter
ERROR: <poky.git>/meta/recipes-core/images/build-appliance-image_15.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'debugfs_vmdk' - possibly invalid type name or missing support class
ERROR: Failed to parse recipe: <poky.git>/meta/recipes-core/images/build-appliance-image_15.0.0.bb
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
i.e. bitbake doesn't even finish parsing...
Since IMAGE_FSTYPES_DEBUGFS is based on IMAGE_FSTYPES, and
since the build-appliance-image is setting IMAGE_FSTYPES
to vmdk, image.bbclass/image_types.bbclass will be trying
to build a debugfs_vmdk, causing the error, as this is not
implemented.
One solution to solving this problem could be as simple as
adding a line
IMAGE_FSTYPES_DEBUGFS_remove = "vmdk"
to the build-appliance-image recipe, but that is very
specific to the error encountered and carries the risk of
the error being reintroduced in another recipe.
Another solution could be to add 'debugfs_vmdk' to
IMAGE_TYPES_MASKED in image-vm.bbclass, but again, this
approach doesn't seem generic enough.
None of the live and vm type images have an implementation
for building a debugfs version, it doesn't seem to make
sense to build debugfs versions of any of them anyway, and
given IMAGE_TYPES_MASKED appears to be intended for those
image types exclusively, it seems the right approach is to
unconditionally also mask all debugfs_ flavours from
IMAGE_TYPES_MASKED to achieve a generic solution.
Do that so.
(From OE-Core rev: 9bd682c4f1c19d68c573c11822888ee799809272)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debugfs is supposed to be used in addition to the
normal image for debugging purposes, it doesn't make
sense to artificially limit its maximum size.
(From OE-Core rev: 7cdf3b2444df8cd322d9eff1bdbdc5adddcaf22a)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 33b0d940b09a5ce1462476614213a58d3d62e80d)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding image_complete task should make sstate machinery
to generate manifest for deployed images and do final
deployment to DEPLOY_DIR_IMAGE.
Made sure IMGDEPLOYDIR doesn't contain images from past deployments
to prevent them to be included into sstate manifests.
Set stamp-extra-info flag for do_image_complete task. This flag
is used in the name of sstate manifest. Setting it to predetermined
value for image_complete should help to get correct manifest
filenames when processing runQueueTask events.
(From OE-Core rev: d54339d4b1a7e884de636f6325ca60409ebd95ff)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed deployment directory from DEPLOY_DIR_IMAGE to
IMGDEPLOYDIR to make sstate machinery to do final deployment and
generate manifest.
Renamed variable deploy_dir to deploy_dir_image in selftest code
to avoid confusion with DEPLOYDIR variable.
Updated the code of rootfs.py:Rootfs class to use IMGDEPLOYDIR variable
as it's now used as a new deployment destination.
(From OE-Core rev: 6d969bacc718e21a5246d4da9bf9639dcae29b02)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a preparation for changing deployment directory for image
and populate_sdk targets.
Introduced new variables, IMGDEPLOYDIR and SDKDEPLOYDIR. Set it to current
image/sdk deployment locations.
(From OE-Core rev: 8969b885044eb46dba3dbf62a0243aef673443d3)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the enhanced functionality, the term "compression" is no longer
accurate, because the mechanism also gets used for conversion
operations that do not actually compress data.
It is possible to remove this naming problem in a backward-compatible
manner by including COMPRESSIONTYPES in CONVERSIONTYPES and checking for
the old COMPRESS_CMD/DEPENDS as fallbacks.
[YOCTO #9346]
(From OE-Core rev: 9d68c024790850cab72ead1e3372a5fcec4ef7b0)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This task runs all functions in IMAGE_QA_COMMANDS after the image
construction has completed in order to validate the resulting image.
Image sanity checks should either be Python functions which raise
bb.build.FuncFailed on failure or shell functions with return a
non-zero exit code.
Python functions may instead raise an oe.utils.ImageQAFailed
Exception which takes an extra argument, a description of the
failure.
python image_check_python_ok () {
if True:
raise bb.build.FuncFailed('This check always fails')
else:
bb.note("Nothing to see here")
}
image_check_shell_ok () {
if true
exit 1
else
exit 0
fi
}
[YOCTO #9448]
(From OE-Core rev: c9bef2ecf1a30159d11781184829f41844a58c13)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new task progress functionality to report progress during
do_rootfs. This is a little coarse and ideally we would have some
progress within the installation section, but it's better than
nothing.
(From OE-Core rev: 370f08d434480c1790950e40db8f7687da78cb14)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to chdir() when creating image symlinks, and using chdir()
changes the state for future tasks.
(From OE-Core rev: 2fdf06fbe986d742f6bb13e9348b50e9aab03139)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do exact match for rootfs type, instead of pattern match, to avoid
unexpected build error due to redundant rootfs type build.
E.g. when building ext2.gz.u-boot, both .gz.u-boot and .u-boot are matched,
the following build error will appear, actually .u-boot is not needed.
| mkimage: Can't open .../core-image-minimal-<machine>-<yyyymmddhhmmss>.rootfs.ext2.gz: No such file or directory
(From OE-Core rev: 46bc438374de74af76d288520c6252c9b7840767)
Signed-off-by: Zhenhua Luo <zhenhua.luo@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If /init is just a symlink to /sbin/init, debugfs creation
fails with the following error:
ERROR: Error: The image creation script '<...>/debugfs.create_image.cpio' returned 1:
touch: cannot touch '<...>/cpio_append/init': Permission denied
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_rootfs
The reason is that IMAGE_CMD_cpio() is run twice on the same
WORKDIR. The first run creates a symlink in WORKDIR/cpio_append/init
to point to /sbin/init, while the 2nd run then tries to 'touch'
that link, which will fail, of course since /sbin/init is not
usually writable by non-root users.
Fix this by providing knowledge to the IMAGE_CMD_xxx() scripts
with regards to the fact that they are being executed in the
context of debugfs creation. The IMAGE_CMD_cpio() can now be
intelligent in the sense that it can avoid all additional symlink
handling during the debugfs run. The symlinks do not need to
be part of the debugfs, so we can skip that part altogether
in that case.
(From OE-Core rev: 659ae1d7df28115429f6f31450fad6d1f86e3031)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a symlink does not get created, it is useful for debugging to log
what would have been created and why it was skipped.
(From OE-Core rev: d2b4da7d21ce5295442bd2d5c760e64cf843aabb)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ed Bartosh <eduard.bartosh@intel.com>
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a derived distro adds a certain type, say zip, to
COMPRESSIONTYPES and later OE-core does the same, we end up with the
type being listed twice, and that would have undesired effects
(commands generated twice).
So to support such loosely coupled extension, we de-duplicated the
list of types first.
Alternatively, such a situation could also be treated as error. But that
seems unnecessary because typically commands for the same type will also
do the same thing.
(From OE-Core rev: 85855af359c2c3bfc1eaa942c95f1f7d7cc6698e)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ed Bartosh <eduard.bartosh@intel.com>
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
remain_features uses a dict which means the order is not deterministic. This
can lead to the task hash changing depending on the state of the memory at
parse time. This is particularly noticeable under python v3.
Since the dict is helpful in constructing the data, pass the data through
sort() so the order is always deterministic.
(From OE-Core rev: b08344e28dd33e3af5596007b11185d04fce255e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case of chained conversion methods are used via COMPRESS_CMD_*
there is chance that some of steps would be executed multiple times.
[YOCTO #9482]
(From OE-Core rev: 94f61c2682e5cfd819ac84535650c3e0a654415a)
Signed-off-by: Alexander D. Kanevskiy <kad@kad.name>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
IMAGE_CMD_xxx commands are always inlined within do_image_xxx.
When IMAGE_CMD_xxx is defined as a function (e.g. IMAGE_CMD_btrfs,
IMAGE_CMD_cpio, etc), a redundant copy of the function will be emitted
by default. Remove IMAGE_CMD_xxx 'func' flags to prevent that.
(From OE-Core rev: 118c1ca4d8d62162e87caf287f96d90707ee5903)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #9487]
The debug filesystem file name is ending in "debug_tar", it should be simply
"tar". Strip the "debug_" piece as necessary.
To avoid deleting the tar ball, when we've asked for just the tarball we need
to check 't' and not 'realt'.
The two hunks were suggested by RP. I've implemented and verify they work
with the settings:
PACKAGE_CLASSES = "package_rpm"
IMAGE_GEN_DEBUGFS = '1'
IMAGE_FSTYPES_DEBUGFS = "tar.bz2"
IMAGE_FSTYPES_DEBUGFS = "tar.gz"
and
IMAGE_FSTYPES_DEBUGFS = "tar"
(From OE-Core rev: ca088bebfc3603ef206b20501916019f0572f955)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove duplicate ROOTFS_POSTPROCESS_COMMAND in the rootfs_command_variables list.
Add DEB_PREPROCESS_COMMANDS and DEB_POSTPROCESS_COMMANDS to rootfs_command_variables
list for consistency with the RPM_ and OPKG_ versions of those variables.
Note: the package manager specific pre and post process commands
may removed entirely in Yocto 2.2 or later.
(From OE-Core rev: e951a8970b456de71f6596f061211a48adce3e3a)
Signed-off-by: Bill Randle <william.c.randle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's some code dotted around OE that uses (a, b)[foo < bar] instead of the
more idiomatic "test and a or b". Or in this case, just max().
(From OE-Core rev: 7ee49f8a41b4b5c48fd283ac2768564c7ebb5332)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debugfs prefix is striped from t, but not from baset.
Therefore baset never matches t.
(From OE-Core rev: 2862cbf74925cb084d3f9c206d3448112ba6a0aa)
Signed-off-by: Freudiger Raphael <raphael.freudiger@siemens.com>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the common code to live_vm_common.bbclass and remove duplicated ones.
(From OE-Core rev: 4a70cc59a0350f06d4cc48c12c3053a39191ba07)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the list of packages that are considered unneeded for a
read-only rootfs was hardcoded. This made it impossible to, e.g., have
shadow installed on a system with a read-only rootfs, but where /etc
is mounted writable.
This also lists ${VIRTUAL-RUNTIME_update-alternatives} rather than
update-alternatives (as was previously the case) since this should
actually remove the intended package.
(From OE-Core rev: e3b881d4168e5b02ff00f5c470ba472ab8bbc747)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently do_wicenv task is run for all images. However, its
result is used only to produce wic image. It's better to
run this task only for wic images. If another rootfs is
required to produce wic image, dependency to its do_wicenv
must be added to the wic image recipy.
Stopped running do_wicenv for all images. Added explicit
dependency to this task in wic-image-minimal recipe.
[YOCTO #9095]
(From OE-Core rev: b81c176fb2f1ee818b6049c39ef353a7d7d5e078)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie
Ming Liu
Tom Rini
Gerson Fernando Budke
Alexander Kanavin
Randy Witt
Nathan Rossi
Ed Bartosh
Joshua Lock
Paul Eggleton
Robert Yang
Peter Kjellerstedt
Andre McCurdy
André Draszik
Patrick Ohly
Ross Burton
Zhenhua Luo
André Draszik
Alexander D. Kanevskiy
Mark Hatle
Bill Randle
Freudiger Raphael