How to order an 'imagebuilder install' phase before 'linux install' phase?

I modify a final image built by OpenWRT by modifying an openwrt_root/target/linux/xxx/image/Makefile file (I added an additional partition for a recovery purpose, this partition consists of kernel/dtb and several binaries, these binaries get installed by using imagebuilder (I created a ./root directory, installed opkg packages I need, into this directory, copied a kernel/dtb and made a squasfs image from this ./root directory) ). To achieve this I, at first, built an OpenWRT with a CONFIG_IB=y option, got a openwrt_root/build_dir/target-xxx/xxx-imagebuilder-xxx-x86_64 directory with imagebuilder 'things' inside, and then changed an openwrt_root/target/linux/xxx/image/Makefile file as described above and repeted an OpenWRT build.

So, the question is - is it possible to achieve this for one pass? (now I can't do it, 'cause the imagebuilder gets installed AFTER openwrt_root/target/linux/xxx/image/Makefile gets control).

I guess I have to change the order of an 'imagebuilder install' and a 'linux install' phases.
This is what I see when I run make -j8:

 make[2] target/install
 make[3] -C target/toolchain install
 make[3] -C target/linux install
 make[3] -C target/imagebuilder install
 make[2] package/index
 make[2] checksum

It seems these phases are run concurrently...

I tried to change an openwrt_root/target/Makefile file like this:

index 7ad26c7..63acc6f 100644
--- a/Makefile
+++ b/Makefile
@@ -7,9 +7,9 @@
 curdir:=target
 
 $(curdir)/subtargets:=install
-$(curdir)/builddirs:=linux sdk imagebuilder toolchain
+$(curdir)/builddirs:=imagebuilder linux sdk toolchain
 $(curdir)/builddirs-default:=linux
-$(curdir)/builddirs-install:=linux $(if $(CONFIG_SDK),sdk) $(if $(CONFIG_IB),imagebuilder) $(if $(CONFIG_MAKE_TOOLCHAIN),toolchain)
+$(curdir)/builddirs-install:=imagebuilder linux $(if $(CONFIG_SDK),sdk) $(if $(CONFIG_MAKE_TOOLCHAIN),toolchain)
 
 $(curdir)/sdk/install:=$(curdir)/linux/install
 $(curdir)/imagebuilder/install:=$(curdir)/linux/install`

, but nothing happened...

Thanks in advance for any help.

I've never heard of needing to alter the build order so dramatically, certainly not from anyone using the image builder.

It sounds like you're following some "instructions" somewhere for some "hack".

Understanding exactly what you're trying to accomplish may lead to a solution.

Changing the order of lines in a Makefile seldom changes execution order -- That's the point of Makefiles; describe the dependencies, make figures out the order.

Edit:

At least from what you've described, assuming you're wanting an image with multiple kernels and packages in different places, you could probably accomplish it through proper modification of the image-generation phase. I'm not at all sure why you need image builder, as you already have the kernel binaries, packages, and tooling to create an image without packing that up into the image builder.

Have you considered how you're going to flash / upgrade this?

1 Like

Thanks a lot for help.
Sorry for a late answer, we had holidays :slight_smile:

When I started to work on this task, I had found the ImageBuilder [IB] as a solution. At first I wanted to assemble a firmware (partition table, u-boot, boot partition and recovery (root-fs) partition) from packages I need, using the IB, and then 'dd' recovery (root-fs) partition from the firmware image file. Then I thought, what a reason to build the firmware if I can just compose a recovery (root-fs)
using the IB (I followed this way at a moment of my question). The next simplification is what you suggested: compose a recovery (root-fs) without IB at all, I didn't think about it, thanks you for this way :slight_smile:

Have you considered how you're going to flash / upgrade this?

Yes, I modified an image-generation phase and now the firmware (image file) consists of partition table, u-boot, boot partition, system (root-fs) partition and recovery partition (with a kernel and binaries from several opkg packages I need plus a copy of a compressed system partition).

Also a sysupgrade script got an ability to perform a full upgrade alongside with upgrading only a system (root-fs) partition.

make -j8 will do things concurrently, to use 7 extra CPU cores (if available on the build machine) to speed up the build. make -j1 (the default) will run on only one core and do one task at a time sequentially.

Multiple jobs may not always work because there isn't complete logic to prevent a new process starting up before a parallel process has finished the files that it needs. This is particularly the case when source code must be downloaded.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.