Modifying pre-install script before installation & packaging

[Liz MacLean]

Hi there!

I’m using swupdate with Yocto, and I’m encountering an issue where I’m trying to modify my pre-install.sh file prior to it being packaged in the .swu file. I have my own image recipe that inherits swupdate-image, and I’ve tried the following to run a sed command on the following appends/prepends in my recipe:

do_fetch
do_unpack
do_rootfs
do_swupdate_copy_swdescription
do_swuimage

Furthermore, I also tried patching swupdate-image directly, with the sed command happening in do_unpack, but that didn’t work either. In most cases, the file would either be replaced just in the WORKDIR, or it would be replaced in WORKDIR/PN, but seemingly after the .swu was made. Is there a known way to update files that will be in sw-description/the package?

My bbpatch file for the recipe I’m using, in essence:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI:append = " \ file://sw-description \ file://pre-install.sh \ file://post-install.sh \ " inherit swupdate-image do_rootfs:append() { // custom stuff } do_install:prepend() { echo "TARGET_ENVIRONMENT = \"${TARGET_ENVIRONMENT}\"" sed -i 's/@@TARGET_ENVIRONMENT@@/${TARGET_ENVIRONMENT}/g' ${D}/pre-install.sh }

Hopefully this is the correct place to ask about this - it feels like swupdate is doing something behind the scenes that I’m not quite grasping, perhaps caching the file elsewhere that I haven’t tried accessing/modifying.

Thanks for your time,
Liz

​

[Liz MacLean]

Looking a little deeper, I think the issue may be that in `swupdate-common.bbclass`, do_swuimage doesn't use the WORKDIR, and instead uses the SRC_URI resources directly, which as a result means any modification to the files after they have been declared in the SRC_URI goes unnoticed. Is there a recommended approach for working around this?

[Stefano Babic]

Hi Liz,

On 20.06.24 17:04, Liz MacLean wrote:
> Looking a little deeper, I think the issue may be that in
> `swupdate-common.bbclass`, do_swuimage doesn't use the WORKDIR, and
> instead uses the SRC_URI resources directly, which as a result means any
> modification to the files after they have been declared in the SRC_URI
> goes unnoticed. Is there a recommended approach for working around this?
>

It is not a package recipe, it is an image recipe. The result is not a
package. The class adds back do_fetch() to add local files, but build
runs for an image and not for a package.

The class searches for artifacts in SRC_URI and DEPLOY_DIR. They are
taken to be packed together and not to be reworked, with the exception
of sw-description.

As already stated oin this ML, using a pre-install shell script is
highly discouraged, because it breaks streaming. The right way to do
some homework before installing is to add a Lua embedded script into
sw-description, where variable substitution is also supported (you do
not need any sed script).

Best regards,
Stefano Babic

> Hopefully this is the correct place to ask about this - it /feels/

> like swupdate is doing something behind the scenes that I’m not
> quite grasping, perhaps caching the file elsewhere that I haven’t
> tried accessing/modifying.
>
> Thanks for your time,
> Liz
>
> ​
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/4356799b-f4cf-43ae-a1ba-dcd9e7fd5cddn%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/4356799b-f4cf-43ae-a1ba-dcd9e7fd5cddn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Liz MacLean]

Thanks for getting back to me Stefano, I really appreciate it! I'll look into using a Lua embedded script instead, thanks!
Liz