| Age | Commit message (Collapse) | Author |
|---|
|
The looping checking the individual bundles used the wrong variable
name and thus failed to gather all additional image features from the
individual bundles.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
Choosing bundle features based on some (rather arbitrary) bundle name
suffix does not scale. Currently it does not support ptest-pkgs and
dbg-pkgs. Adding support for those via bundle name suffix would become
rather awkward.
So instead we now allow (and require!) that bundle features for a
bundle named "foo" are set explicitly in BUNDLE_FEATURES[foo]. The
corresponding content has to be in BUNDLE_CONTENTS[foo].
There's no sanity checking that features listed there are really
suitable for a bundle. Features adding content (like ptest-pkgs,
dbg-pkgs, dev-pkgs) are okay, features changing the os-core are not
(like debug-tweaks). This cannot be checked automatically by
meta-swupd because there is no definite list of acceptable features.
This is an API change. Users of meta-swupd need to be adapted.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
We already unset IMAGE_FSTYPES to prevent any images being written
for the transient bundle images. As a logical follow on from that
change, and to prevent issues when trying to build for a MACHINE
which supports live images (due to the automatic inference of
live image support via build_live() in image.bbclass), delete the
do_bootimg task for bundle images.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
|
This reverts commit a7dddfbfb8f45989856c93c6f82f46d8a96e6f0b.
We can't completely disable the do_image task because we need to
allow various tasks that run during image creation which affect
the rootfs to run.
|
|
Mark do_image and do_bootimg as noexec tasks so that they don't run
but their task dependency chain is preserved. This prevents an error
in swupdbundle image building when an image for the target MACHINE
would result in a live image being built.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
|
By convention, any bundle called "foobar-dev" is equal to the "foobar"
bundle plus the "dev-pkgs" image feature, i.e. it has the same content
as the base bundle plus the corresponding development files.
Without this feature it is impossible to generate separate bundles for
development files; the only option would be to put "dev-pkgs" into the
shared image features, which would add development files also to the
os-core and all bundles.
Using this fixed naming convention was chosen over additional
configuration options because a consistent naming automatically gets
enforced and it was easier to implement than additional configuration
options.
A future optimization will be to declare a dependency of the -dev
bundle on the base bundle and only provide the additional development
files in the -dev bundle. Right now, the -dev bundle is simply a
larger variant of the base bundle because all non-development files
are present in both bundles.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
All that we need from virtual image recipes is the output of do_image.
That will run regardless whether there are image types defined.
Instead of producing image files and removing them later (which, besides
wasting time and IO bandwidth, was also not done completely when using
this class in Ostro OS) we can skip the entire image file creation
by unsetting IMAGE_FSTYPES.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
Having virtual recipes named "${PN}-<bundle>" (example:
ostro-image-iotivity for ostro-image.bb) is potentially problematic,
because there might also be a real recipe with that name
(ostro-image-iotivity.bb).
Now the virtual recipes use "bundle-" as prefix in their name.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
It should be possible to use swupd-image to create images with an
update stream regardless of whether bundles have been defined for
the image or not.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
|
This initial layer version provides an initial set of metadata to enable
integration of the swupd (https://clearlinux.org/features/software-update)
software updater into an image.
Approach:
An image that inherits the swupd-image bbclass will automatically have
bundle 'chroots' created which contain the filesystem contents of the
specified bundles, with the contents of the inheriting image forming the
default os-core bundle.
The mechanism to achieve this is that several virtual image recipes are
created using the swupdbundle class, one for each defined bundle plus a
'mega' image recipe. The 'mega' image contains the base image plus the
contents of all of the bundles, whilst bundle images contain only the
base image plus the contents of a single bundle.
We build the mega image first, then the base image (the one which
inherits this class) and finally all of the bundle images. Each
non-mega image has a manifest generated that lists the file contents
of the image.
We took the approach of building images, rather than populating the
chroot-like bundle directories with a package manager, because various
layers and recipes make changes to the rootfs contents outside of the
package manager, particularly with IMAGE_POSTPROCESS_COMMAND, etc.
Once the images and their manifests have been created each bundle image
manifest is compared to the base image manifest in order to generate a list
of files in the bundle image which don't exist in the base image.
Files in this list are then preserved in the bundle directory for
processing by swupd-server in order to generate update artefacts.
Finally the binaries from swupd-server are called on the bundle directories
to generate the artefacts for consumption by a swupd client.
How to:
* inherit the swupd-image class in your core OS image. swupd-based OS's use
bundles, the primary one of which, os-core, is defined as the contents of
this image.
* Assign a list of names for bundles you wish to generate to the
SWUPD_BUNDLES variable i.e.
SWUPD_BUNDLES = "feature_one feature_two"
* Assign a list of packages for which their content should be included in a
bundle to a varflag of BUNDLE_CONTENTS which matches the bundle name i.e.
BUNDLE_CONTENTS[feature_one] = "package_one package_three package_six"
* Ensure the OS_VERSION variable is assigned an integer value and increased
before each image build which should generate swupd update artefacts.
This variable must echo the same version number as is used to set the
VERSION_ID field of os-release as swupd-client will use it to check for
updates.
* Publish the contents of
${DEPLOY_DIR}/swupd/${MACHINE}/${IMAGE_BASENAME}/www on a server for
consumption by swupd-client
* Use swupd client sub-commands with the -u argument pointing to the
contents published above
Known issues:
* shared pseudo database: the bundle chroot-like directories are generated
per-recipe and processed by a task of the inheriting recipe. In order for
the files generated outside of the base recipe to have correct
permissions when processed by swupd-server we need to share a pseudo
database across the recipes.
This database is currently never cleaned up, which is likely to cause
headaches due to the way pseudo operates on inodes that could be reused
outside of pseudo's influence. We have yet to determine an appropriate
time to perform housekeeping on this database (we essentially need the
database to be removed when DEPLOY_DIR_SWUPD is removed).
* oe-swupd-helpers: this recipe provides stub implementations only of some
swupd-client helpers. Anyone wishing to utilise swupd in a deployed image
will need to at least override kernel_updater.sh and
systemdboot_updater.sh.
* hard-coded paths: swupd assumes Clear Linux as a host OS and hard-codes
several paths to directories, programs and configuration files on Clear.
* builds a lot of images: due to the approach taken there are n+2 images
built, where n is the number of bundles defined in SWUPD_BUNDLES.
* creates a lot of duplicate files: due to the way swupd works by
processing chroot-like bundle directories on each os release we
potentially end up carrying a lot of duplicate files in DEPLOY_DIR_SWUPD.
We intend to look at using the hardlink program to replace duplicate
files in that directory with hard links in order to save disk space.
* requires far more testing: there are a lot of combinations of bundle
contents, rootfs modification commands (IMAGE_POSTPROCESS_COMMAND,
IMAGE_PREPROCESS_COMMAND, etc) that can affect the inputs to swupd and
our testing has likely missed areas of issue.
* OS_VERSION: introduces a new variable for the OS version number when we
already have a DISTRO_VERSION variable. This was done because swupd makes
various assumptions about the version number which aren't necessarily
true for traditional DISTRO_VERSION values in OE et al.
Co-authored-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
|
Patrick Ohly
Joshua Lock