Bug 10108 - file ownership is not preserved when IMAGE_BASENAME is changed in image recipe
Summary: file ownership is not preserved when IMAGE_BASENAME is changed in image recipe
Status: RESOLVED FIXED
Alias: None
Product: Other YP Layers
Classification: Build System, Metadata & Runtime
Component: meta-swupd (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.2
Assignee: Joshua Lock
QA Contact: David Rodriguez
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-08-10 14:37 UTC by Piotr Figiel
Modified: 2016-08-16 12:54 UTC (History)
1 user (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Figiel 2016-08-10 14:37:02 UTC
There is an issue resulting in quite bizarre side effect on the target. First noticeable effect is that the mount command refuses to work when booting an image inheriting from swupd-image.bbclass. Mount exits with error because it suids to non-root UID.

This is reproducible when IMAGE_BASENAME is changed at image recipe level and happens because the file ownership is not preserved on the final rootfs when some copying is done by the swupd class. It was tested with single additional (non os-core) bundle.

The root cause seem to be related with the fact that depending on context swupd-image.bbclass uses either PN (PN_BASE) or IMAGE_BASENAME when generating path to pseudo shared state directory. This seems correct only when IMAGE_BASENAME is not set as it defaults to PN.

Following patch (on top of master b1ed8bf09ea7) seem to resolve the problem:

diff --git a/classes/swupd-image.bbclass b/classes/swupd-image.bbclass
index 08ab3f5..e85ccf5 100644
--- a/classes/swupd-image.bbclass
+++ b/classes/swupd-image.bbclass
@@ -81,7 +81,7 @@ python () {
         # Because real image building via SWUPD_IMAGES can happen also after
         # the initial "bitbake <core image>" invocation, we have to keep that
         # pseudo database around and cannot delete it.
-        pseudo_state = d.expand('${TMPDIR}/work-shared/${PN_BASE}/pseudo')
+        pseudo_state = d.expand('${TMPDIR}/work-shared/${IMAGE_BASENAME}/pseudo')
         d.setVar('PSEUDO_LOCALSTATEDIR', pseudo_state)
 
         # Non mega virtual images must depend on the mega image having been
@@ -191,7 +191,7 @@ fakeroot do_rootfs_append () {
         swupd.bundles.create_bundle_manifest(d, bundle)
 }
 
-do_image_append () {
+fakeroot do_image_append () {
     import swupd.rootfs
 
     swupd.rootfs.create_rootfs(d)
Comment 1 Joshua Lock 2016-08-10 16:07:28 UTC
(In reply to comment #0)
> There is an issue resulting in quite bizarre side effect on the target.
> First noticeable effect is that the mount command refuses to work when
> booting an image inheriting from swupd-image.bbclass. Mount exits with error
> because it suids to non-root UID.
> 
> This is reproducible when IMAGE_BASENAME is changed at image recipe level
> and happens because the file ownership is not preserved on the final rootfs
> when some copying is done by the swupd class. It was tested with single
> additional (non os-core) bundle.
> 
> The root cause seem to be related with the fact that depending on context
> swupd-image.bbclass uses either PN (PN_BASE) or IMAGE_BASENAME when
> generating path to pseudo shared state directory. This seems correct only
> when IMAGE_BASENAME is not set as it defaults to PN.
> 
> Following patch (on top of master b1ed8bf09ea7) seem to resolve the problem:
> 
> diff --git a/classes/swupd-image.bbclass b/classes/swupd-image.bbclass
> index 08ab3f5..e85ccf5 100644
> --- a/classes/swupd-image.bbclass
> +++ b/classes/swupd-image.bbclass
> @@ -81,7 +81,7 @@ python () {
>          # Because real image building via SWUPD_IMAGES can happen also after
>          # the initial "bitbake <core image>" invocation, we have to keep
> that
>          # pseudo database around and cannot delete it.
> -        pseudo_state = d.expand('${TMPDIR}/work-shared/${PN_BASE}/pseudo')
> +        pseudo_state =
> d.expand('${TMPDIR}/work-shared/${IMAGE_BASENAME}/pseudo')
>          d.setVar('PSEUDO_LOCALSTATEDIR', pseudo_state)

Good catch, thanks! Would you be interested in submitting a patch for this to the Yocto Project mailing list?

If not I can make the change and credit you in the commit log.

>          # Non mega virtual images must depend on the mega image having been
> @@ -191,7 +191,7 @@ fakeroot do_rootfs_append () {
>          swupd.bundles.create_bundle_manifest(d, bundle)
>  }
>  
> -do_image_append () {
> +fakeroot do_image_append () {
>      import swupd.rootfs
>  
>      swupd.rootfs.create_rootfs(d)

I don't think this change should be required? The do_image task in image.bbclass already sets the fakeroot flag.
Comment 2 Piotr Figiel 2016-08-11 10:07:56 UTC
Hi,
 thanks for looking at this. I sent the patch to openembedded-devel@lists.openembedded.org, I hope the company's SMTP server didn't break it in the process.
 You are right regarding the fakeroot amendment, it worked without it.
Comment 3 Joshua Lock 2016-08-11 10:23:59 UTC
(In reply to comment #2)
> Hi,
>  thanks for looking at this. I sent the patch to
> openembedded-devel@lists.openembedded.org, I hope the company's SMTP server
> didn't break it in the process.
>  You are right regarding the fakeroot amendment, it worked without it.

Unfortunately this is the wrong list, meta-swupd patches should go to yocto@yoctoproject.org per the README:

"please send them to the Yocto Project mailing list <yocto@yoctoproject.org> with '[meta-swupd]' in the subject line."

I would have taken the patch from the OE list but I don't see it there anyway, you must be a subscriber to send mail to the list.
Comment 4 Piotr Figiel 2016-08-11 12:33:45 UTC
Hi,
I posted it to yocto project.

https://lists.yoctoproject.org/pipermail/yocto/2016-August/031516.html