Help required to fix bug: porting from legacy to generic build form (WNR2000v3, 4/32 device)

on new ath79 tl-wr841n-v9 target I can have luci with squashfs block size set to 1024 and no problems till now, that's why I told you to try that


building now with 1024 instead of the preconfigured 256.

But the build process should still be fixed to not create non-working images.

The ar71xx "architecture" is on its last legs, with significant effort going into the forward-looking ath79 build tree for the same CPUs (allowing newer kernels to be used, among other things). "Fixing" the build system for a soon-to-be-deprecated architecture that does build valid images is unlikely to be a priority, unless you or someone you know are personally motivated to take on the work yourself.

1 Like

@mhoxjwwi Is there a report on the bug tracker about this? If not, why not file one?

1 Like


Take a look at the first forum post. The link to the bug is/was:

I highlighted it on the ML a few minutes ago.

@mhoxjwwi Now's your chance:

The device is working fine. Just fix the BUILD SYSTEM! Wtf, why would you want to remove the support for the device? Its working fine without Luci and there are the perfectly fine working snapshot images:

I am reporting here an issue that the build system buids too large images for a device and then you want to thank me for the report of the error by dropping support for my device?
The build system should calculate the max possible size and if a build image is bigger then that, then dont upload non-working-too-big images as stable releases to the servers.

No, what is happening is the following:

  • you reported the issue
  • no developer seems to be able to or care about fixing this device, as it's not just moving it to the tiny target but also migrating it to the new target using dts files instead of the old system, as the whole ar71xx is going to be deprecated in years. And this device is on its last legs as far as ram and flash, so it won't last much longer anyway.
  • the choice becomes either shipping a broken firmware upgrade or dropping support for this device

Note that deleting a device from a project managed with modern source versioning systems (like git) isn't permanent, anyone can just check the source code at the moment in time before someone deleted your device and all things will be exactly as they were, which can be useful if someone interested in porting the device over to fix it shows up.

1 Like

It would stop having fully fine working snapshot images with all security relevant things like build in WPA2-KRACK fix and so on. Every user of this device would then have to know how to use build system, how to use git to revert things, ...
This would be insane additional amount of work for users who can now just download a file and install it.

Download a file without luci and without much space to install anything at all, yeah. I quite frankly don't get why the WNR2000 series of routers has so much fans out there, I've also helped people in a PR (that was never merged) to build a firmware for their WNDR2000v4 I think and many people were interested.

My devices with 4mb flash can only be used with firmware images created with the Image Builder or from source, unless you're fine with ssh only and base system only, which is quite meh imho.

But if you insist that it's good to keep the snapshot building, you can ask them (on the mailing list possibly) to drop this device only from the release branch, so it won't have a 18.06 firmware, but the snapshots will still be built for it.