Struggling to use imagebuilder for new device

I am trying to build a "production" image for a supported device that didn't land in time for 21.02. According to a tip I got at Netgear GS308T "snapshot" vs. GS108T v3 "21.02.1" support - #3 by RaylynnKnight it sounds like this should be possible by applying the patch for the device myself.

I already have a snapshot build installed, but my goal is a sysupgrade image for my Netgear GS308T that's equivalent to the official downloads that I get for my other OpenWrt routers: the stable 21.02 release with LuCI and any other defaults.

I'm using the Docker openwrtorg/imagebuilder container, and what I've done so far is:

# starting on host
mkdir output
chown 1000:1000 output      # conveniently, this matches my user account on host
docker run -it --rm --user build \
  -v "$(pwd)"/output/:/home/build/openwrt/bin \

# within container
patch -p1 < c829bc1.patch

make image PROFILE=netgear_gs308t-v1

But that failed because apparently the profile information does not come from the makefiles that got patched but a hardcoded .targetinfo file that comes built into the container:

Profile "netgear_gs308t-v1" does not exist!

So what I tried next was to grab a copy of that file from a snapshot imagebuilder and use it back in the 21.02 container:

# back on host
docker run --rm --user build \
  -v "$(pwd)"/output/:/home/build/openwrt/bin \
  openwrtorg/imagebuilder:realtek-generic-snapshot \
  cat .targetinfo > snapshot-.targetinfo

docker run -it --rm --user build \
  -v "$(pwd)"/output/:/home/build/openwrt/bin \
  -v "$(pwd)"/snapshot-.targetinfo:/home/build/openwrt/.targetinfo \      # <-- new

Then repeating the same patch/make image … steps within the container. That got a lot farther — seemingly mostly through the build? — but then ultimately fails with an error:

make[3]: *** No rule to make target '/home/build/openwrt/build_dir/target-mips_4kec_musl/linux-realtek_generic/netgear_gs308t-v1-kernel.bin', needed by '/home/build/openwrt/build_dir/target-mips_4kec_musl/linux-realtek_generic/tmp/openwrt-21.02.1-realtek-generic-netgear_gs308t-v1-squashfs-sysupgrade.bin'. Stop.

At this point I'm ± stuck. My most pressing problem is the missing …-kernel.bin file. Am I missing some sort of steps beyond the new .targetinfo file and simply applying the device support patch that would somehow trigger the proper build of this device-specific file?

It's also a bit disconcerting that the logs up to that point make no mention of any luci-related packages. I assumed that using the 21.02 imagebuilder I would get an "official release"–styled image. Is that not the case? What is the recommended way of replicating basically the same 21.02 build that the already-supported GS108T has available, but for my newly-supported GS308T router instead?


Just use the already built snapshot images. There have been many fixes that would be beneficial.


Ah, then perhaps sticking with the snapshots would be the most straightforward solution.

I think in my head I conflated "using LuCI on snapshot" with "needing to build your own image" — only because the one other device I have still stuck on snapshot has barely a few kilobytes of flash to spare outside of the squashfs. But I suppose that won't be nearly such an issue with the GS308T given its 32MB flash.

luCi is not included with Snapshot images AFAIK, but you can just opkg update && opkg install luci-ssl via ssh/console, or, you can use ImageBuilder (or by checking out to include the luci packages you want baked in by default.

1 Like

Apart from the fixes in snapshots, master has also moved on to kernel v5.10 and has undergone quite significant refactoring to align with mainline and newer SOC support. It's not safe (nor necessarily easy, depending on the device) to apply the patches adding new device support to the openwrt-21.02 branch.

Details vary between devices, in some cases it may be easy, in others it might break spectacularly or even brick the device, unless you are experienced and have substantial means of recovery, keep the device support in its natural (~tested) environment.

Your basic error is trying to use the imagebuilder.

If you want to patch OpenWrt sources, e.g. add a new device, you should use the full toolchain and compile everything from scratch (like wulfy23 already hinted). The patch adds content to the network scripts plus DTS definitions that need to be compiled.

The imagebuilder is meant for quickly cooking up the image from already compiled modules, e.g. for adding packages to the image. It can't be used as a real compiler.


If you aren't aware of the versioning scheme @natevw, it's derived from YY.MM.xx that the branch was locked. 19.07 (July, 2019), 21.02 (February, 2021), etc..

Aside from security/update releases (the xx, like 19.07.8, 21.02.1,etc), the branch itself doesn't change. This is why building from master, which not "officially released" is always going to be the best code-base to use if you are capable of doing so.

1 Like

Ah! Thanks for clarifying. I'd seen some mention of the toolchain vs. imagebuilder in other threads without fully understanding the distinction. The container I was using included the relevant source that needed to be patched and seemed to be installing gcc and such, but I wasn't paying close enough attention.

That definitely explains why there's no "easy" way to update the .targetinfo since it sounds like the whole checkout and build folder mostly exist for the purpose of metadata pointing to prebuilt binaries and the main point of imagebuilder is to assemble them.

As far as the versions, it sounds like master then is not terribly experimental? The switch is going into a fairly low stakes environment but a "production" one nonetheless [home network]. That's why I was aiming for the 21.02 build (and the original patch pre-dated the 5.4/5.10 split in the dts folder) to avoid being an alpha tester of unrelated work.

But iirc it was @RaylynnKnight who added support for this particular device and I take their word that snapshot is better anyway for this device. I checked the device support patches themselves for any updates since and didn't see any changes to those (besides splitting into the 5.4/5.10 copies), so I assume the improvements have come in terms of the realtek platform or kernel generally.

Normally master is stable enough, but right now there is the ongoing transition from iptables based firewall3 to nftables based firewall4. Some features are buggy right now.

All new devices are added to master, so if you ever hope to get the device into OpenWrt, you need to implement it in the master.

1 Like

At least for the device in question, an rtl838x based switch, the more advanced firewall addon packages (which may cause problems, e.g. banip, sqm, etc.) aren't really relevant (and the fw4 core is solid), so it shouldn't matter here.