Updated packages when building firmware image

I would like to build an image of a release version with a few packages built-in.

So I checked out the 19.07.3 branch and installed the packages from the package feeds.

git clone https://github.com/openwrt/openwrt.git
git checkout v19.07.3
cd openwrt
./scripts/feeds update -a
./scripts/feeds install -a

When you build an image, the package versions In the manifest are those from when 19.07.3 was released, even though newer versions of certain packages are available in the feed, when you update the list of available packages and say "opkg list-upgradable".

How to compile the latest versions of available packages into the image?

you have to be in the openwrt folder first before checking a particular branch.

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git checkout v19.07.3
./scripts/feeds update -a
./scripts/feeds install -a

My mistake. There's a mistake in the post, but I did change to the openwrt folder before checking out the branch. The kernel version is the version of the branch, it's that I'm just not getting the updated packages.

git checkout openwrt-19.07

You are building 19.07.3, so you only get the packages that existed at that time. If you want everything latest, then you need to checkout the latest branch.

1 Like

At the time 19.07.3 was released the latest version of luci was luci-git-20.136.49537-fb2f363-1, now there is luci-git-20.140.38620-8d89f0d-1 available from https://downloads.openwrt.org/releases/19.07.3/packages/arm_cortex-a7_neon-vfpv4/luci/

Is there any way to compile these updates into a release firmware image? Can you have something like 19.07.3 core OpenWrt but with the package updates? How would I go about doing this? It's not wise to use development branch in a router you depend on every day, I'm working from home like everyone else during the coronapestilence!

My first thought is that this may be the equivalent of upgrading packages on an active install, except baked into the image. If so, the following applies:

Upgrading packages (via the CLI opkg upgrade command or the LuCI Upgrade... button can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.

However, it may be a different animal entirely. Summoning @jow who is far more knowledgeable than me when it comes to the actual software development angle (and has a different opinion regarding the package upgrade warning).

I saw that discussion. It wouldn't be surprising to hear that someone bricked their router by upgrading something sensitive, like busybox or opkg. That said, I'd actually think it the safer approach to compile a new version of a core package into an image - you just boot up with the new busybox instead of risking pulling the rug out under yourself when you replace it.

Since updates on releases are usually security or bug fixes there must be a way!

I honestly don't know... Brainstorming here...

On the one hand, there is the race-condition risk when upgrading packages on a running system -- that obviously bricks it because of an incomplete /corrupted upgrade. The idea of creating an updated image would fix that potential risk.

However, OTOH, sometimes a fail-safe boot after a failed a running-upgrade will still work because the core binaries stored in ROM are working and self-consistent. If the brick root-cause was compatibility (rather than an interrupted/race-condition type failure during a running-upgrade), the upgraded image method would probably also mean broken failsafe (thus needing tftp or serial recovery).

Again, I'm not a software developer (I am a hardware engineer), and I'm coming at the issue with the approach "Don't upgrade packages unless you understand the risks" because we have seen lots of threads where things go wrong. IMO, better to warn about the risks and be wrong (i.e. turns out okay) than to have lots of users frustrated because OpenWrt is different than the big linux distros.

yes, happens on the next release... when you change the source... by definition it is no longer a fixed release image ( 19.07.3 )...


The image builder grabs the latest version available for each package, and it is not expected to break things. You do not get to configure or modify the compilation, however.

(Although overlooking the possible improvements in the main 19.07 OpenWrt since the 19.07.3 release makes no sense...)


  • Checkout the 19.07 branch, not the fixed 19.07.3.
  • git checkout the commit before or after 19.07.3 release tag (to get the equivalent of 19.07.3 without checking out the tag and locking the feeds). You want commit 85e04e9f46 or c3e3802a8e
  • update feeds normally with "scripts/feeds update" to the HEAD of them, instead of the static 19.07.3

That should produce you the "release 19.07.3 main source" plus "package updates in 19.07 since then".

Relevant git history

Basically the release just temporarily changes the version string, fixes feeds, and that is then reverted immediately after the release and the branch continues again its normal life.

Previous: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=85e04e9f46bf68a8a35e2578ea4083cbf44f12f6
Release: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f3f38f40da74a193b4177be8d0fa746d00a753ea
Normalization after release: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=c3e3802a8effd099481cedf669e3a17840612514

But that (checking out the release) naturally overlooks the possible package updates in the main OpenWrt source base, as only the feeds are updated (most packages, LuCI, etc.).

Note that naturally only pulls the updates from the 19.07 packages feeds, not from master. Master and 19.07 have separate packages feed branches.

So far there haven't been so many changes since 19.07.3, so you are not hurting yourself too much (unless you have a device that has got fixes since then (mainly bcm63xx, ath79))


Much more sensible would be to checkout the HEAD of 19.07 branch and build the quite up-to-date 19.07 build, instead of trying to half-mimic 19.07.3

There is nothing holy about the .point maintenance releases, so it usually pays off to build from the stable branch HEAD.

1 Like

19.07 is not a development branch. I compile it regularly with not issues. I also work from home.

You will create yourself more problems if you follow through on your idea by making a Frankenstein image with non matching core and packages.

1 Like

i wonder since the goal is to stay with a particular branch, would an imagebuilder be more practical to assemble a firmware than to build an image from git? unless one is planning on making images for multiple devices.

Thanks for the detailed reply. This is the solution. (It's clear that I need to learn how git really works.)

Does the imagebuilder permit custom kernel/busybox configurations, or does it use exclusively the default configuration?

Why do you think that keeping one part of an integrated firmware at 19.07.3 and using the latest versions of everything else is a good idea? You will get absolutely the same results if you install 19.07.3 and upgrade packages in place and this practice is discouraged, because it leads to unstable routers. You are gonna do the same thing, but in a more complicated way.

This post was flagged by the community and is temporarily hidden.

No, the image builder just puts together all the packages that were compiled previously, you cannot apply patches or change compilation parameters.