Bug 9039

To clarify, the class is to use swupd-server tool to generate extra artefacts to each image, that would be the current set of files in an image and the list of changes since the previous.

Example:
 - When a build 5160 is done, it generates https://download.clearlinux.org/update/5160/
 - https://download.clearlinux.org/update/5160/Manifest.MoM contains the list of manifests that changed (Manifest-of-Manifest)
 - https://download.clearlinux.org/update/5160/Manifest.os-core contains the list of files that changed in that manifest (os-core is the core of the image, always present)
 - https://download.clearlinux.org/update/5160/files/ with tarballs named after hashes mentioned in the Manifest.* files.

And other files that are optimizations composed on top of these mentioned above. The optimizations are like "packs" that deliver in a single file the whole set of changed files for a given version update.

Igor (now in CC) provided instructions on how to run `swupd-server` and get these resulting artefacts.

Thanks for the clarification, that matches my understanding of the task.

Work is underway on an implementation and we have an initial PoC including various patches to swupd-server to prevent reliance on paths in the host OS.

We're generating all swupd related artefacts in a SWUPD_WORKDIR which defaults to ${TMPDIR}/swupd/${MACHINE}/${IMAGE_BASENAME}. The contents of which, after a successful image build, include:

$ ls www/30/
delta	            	  Manifest-os-core-delta-from-10
files	            	  Manifest-os-core-delta-from-10.signed
format	           	  Manifest-os-core-delta-from-20
Manifest.full	          Manifest-os-core-delta-from-20.signed
Manifest.full.signed	  Manifest.os-core.signed
Manifest.full.tar	  Manifest.os-core.tar
Manifest.full.tar.signed  Manifest.os-core.tar.signed
Manifest.MoM	       	  pack-os-core-from-0.tar
Manifest.MoM.signed    	  pack-os-core-from-0.tar.signed
Manifest.MoM.tar      	  pack-os-core-from-20.tar
Manifest.MoM.tar.signed   pack-os-core-from-20.tar.signed
Manifest.os-core      	  swupd-server-src-version

Of course, publishing the contents of that directory are outside the scope of OE/YP.

(In reply to comment #2)

> Of course, publishing the contents of that directory are outside the scope
> of OE/YP.

As long as the verification is functional, rather than just comparing the directory listing.

Ex:

0) generate images A and B

1) generate swupd feeds for both A and B

2) install image A on device

3) verify that it's ok from the perspective of swupd-client
   swupd verify -L info -vvvvv -u <location where to find swupd feeds>

4) perform the update
   swupd update -L info -vvvvv -u <location where to find swupd feeds>

5) verify that the update was ok
   swupd verify -L info -vvvvv -u <location where to find swupd feeds>


How the feed is deployed to the location fed to swupd is out of scope, yes.
So you can even copy them manually if you like, it doesn't have to be part of the deliverable.

An pull request containing an initial implementation of swupd integration has been submitted to the OE core mailing list:

http://lists.openembedded.org/pipermail/openembedded-core/2016-February/117983.html

The majority of testing so far has been with QEMU machines and a minimal distro on top of the OE Core defaultdistro.

Per the submission's cover letter there are several known issues with the current implementation which I will file bugs for.

This work is now being done in a separate layer, meta-swupd:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd

This is because both swupd and the metadata to integrate it within OE Core are too immature to include in the core at this time. We'll continue to develop this feature in meta-swupd and consider proposing it for inclusion in OE Core in future.

An initial implementation of swupd support is complete with several outstanding items filed as bugs: #9187, #9188, #9189, #9190, #9192 and #9191.

Removing the documentation change flag as I'll handle initial documentation in #9191.

Observation from building the bundles: 
in Ostro context (and also OE?) each bundle triggers the creation of an image.
In Ostro I see that for each bundle the do_image_dsk task is run.

This wastes time and increases the space requirements, because for each bundle it will need to have space for the bundle itself _and_ for the associated image (which has fixed size, irrespectively of the disk occupation of the specific bundle).

As long as the bundle affects only the rootfs, it should be sufficient to stop there.

The problem with the extra images is that an image will be built for every bundle times the depth of the history.

So, taking a very simple scenario with 3 bundles and 2 history steps, that is already 6 image built unnecessarily.

Other finding: the numbering seems to be inconsistent.
This might be a mismatch between this implementation and Ostro.
I had to edit manually the /etc/os-release file on the device to remove a 0 that had been appended, but was missing from the swupd repo.

All the packs of the type

pack-bundlename-from-0-to-version.tar

are missing from the swupd repo.

Ex:

pack-iotivity-from-0-to-123450.tar
pack-soletta-from-0-to-123450.tar


I suspect the cause is the same I mentioned in the previous comment.

I have "fixed" the VERSION_ID from Ostro:
diff --git a/meta-ostro/recipes-swupd/swupd-client/os-release.bbappend b/meta-ostro/recipes-swupd/swupd-client/os-release.bbappend
index a17f581..8daf9c0 100644
--- a/meta-ostro/recipes-swupd/swupd-client/os-release.bbappend
+++ b/meta-ostro/recipes-swupd/swupd-client/os-release.bbappend
@@ -1,4 +1,5 @@
-VERSION_ID = "${@bb.data.getVar('BUILD_ID',d,1).split('-')[-1].join(['', '0']) }"
+#VERSION_ID = "${@bb.data.getVar('BUILD_ID',d,1).split('-')[-1].join(['', '0']) }"
+VERSION_ID = "${@bb.data.getVar('BUILD_ID',d,1).split('-')[-1].join(['', '']) }"


So that now the VERSION_ID from /etc/os-release in the image matches the swupd path /update/intel-corei7-64/ostro-image/www/123450 from the swupd htt server.


However the pack files are still missing.

I tried also with a more domesticated version number (10) but got the same error as described in comment #9.

(In reply to comment #6)
> Observation from building the bundles: 
> in Ostro context (and also OE?) each bundle triggers the creation of an
> image.
> In Ostro I see that for each bundle the do_image_dsk task is run.
> 
> This wastes time and increases the space requirements, because for each
> bundle it will need to have space for the bundle itself _and_ for the
> associated image (which has fixed size, irrespectively of the disk
> occupation of the specific bundle).
> 
> As long as the bundle affects only the rootfs, it should be sufficient to
> stop there.

My initial investigation lead me to believe that it isn't sufficient, there are examples of functionality in various layers run during IMAGE_PREPROCESS_COMMAND (which run after do_rootfs) that modify the files in the resulting image rootfs i.e. prelink_image in OE-Core and ima_evm_sign_rootfs in meta-integrity.

If we copy the bundle contents before these processes are run we may end up with a situation where files in the image are different to the files in the bundle and verification will fail.

I'm not very happy with having to generate multiple images so would be more than happy if you have ideas about how to avoid this?

Whilst the time impact seems difficult to avoid, assuming my analysis above is correct, some effort has been made to reduce the space impact by removing the generated intermediate images once the update has been generated:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd/commit/?id=9e32ae69a4f13b934a396acf15a6c911ea67d7b2

I infer from your comment that this functionality isn't working correctly with the images generated for Ostro?

(In reply to comment #9)
> All the packs of the type
> 
> pack-bundlename-from-0-to-version.tar
> 
> are missing from the swupd repo.
> 
> Ex:
> 
> pack-iotivity-from-0-to-123450.tar
> pack-soletta-from-0-to-123450.tar

That is strange, zero-pack creation works in my testing here and I'd like to understand what's going on. The swupd-image class includes some debugging, the file log.do_swupd_image.PID in the image's temp dir might provide some clues as to what's going wrong?

My logs here have entries like:

DEBUG: Generating zero packs, this can take some time.
swupd-serverupdate pack creator version 2.53
   Copyright (C) 2012-2016 Intel Corporation
   bsdiff portions Copyright Colin Percival, see COPYING file for details

Making pack-os-core 0 to 20
Pack creation complete (pack-os-core 0 to 20)
DEBUG: Generating zero pack for connman
swupd-serverupdate pack creator version 2.53
   Copyright (C) 2012-2016 Intel Corporation
   bsdiff portions Copyright Colin Percival, see COPYING file for details

Making pack-connman 0 to 20
Pack creation complete (pack-connman 0 to 20)
DEBUG: Generating zero pack for server
swupd-serverupdate pack creator version 2.53
   Copyright (C) 2012-2016 Intel Corporation
   bsdiff portions Copyright Colin Percival, see COPYING file for details

Making pack-server 0 to 20
Pack creation complete (pack-server 0 to 20)

Update: we confirmed today that handling of bundles works only partially.
Not because of the finding listed so far, which seem to be "normal", but because the removal of bundles is not working correctly (0 files removed).

Further update:
I tried to reproduce the update of the core os.

This triggered a segfault during creation of packaged deltas, probably something wrong in swupd. It happened when creating the delta from version 10 to version 20.

I followed Joshua's advice to try disabling that feature, with SWUPD_DELTAPACKS = "0" and I finally could update from version 10 installed on a NUC, to version 20.

(In reply to comment #14)
> Update: we confirmed today that handling of bundles works only partially.
> Not because of the finding listed so far, which seem to be "normal", but
> because the removal of bundles is not working correctly (0 files removed).

Per the Yocto Project bug triage meeting today we'd like to mark this issue resolved as the goal of integrating swupd, via meta-swupd, is complete. Any bugs with the implementation should be filed as separate tickets.

The segfault behaviour appears to be fixed by Dmitry's patch to fix freeing of dangling pointers: http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd/commit/?id=9e5731a3aa4b2065f5399094903c6805f8c67170

Which leaves the issue of bundle removal not working as expected, I've filed this as: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9290