Ah - of course it's that 2.8 + 1.3 > 3.538. I presume that the 2.8MB is the rom portion, I'll have to figure out where that 1.3MB is coming from.. Still, only 3.538 left out of 8MB seems like not much at some level..
It seems like there's a hard limit on the rootfs. Does a factory image get generated? Or is there only a sysupgrade image available for your hardware altogether?
A factory image does get generated (if LuCI is deselected). That's how I got LEDE on there from the stock firmware originally.
[Edit: I removed an idea that could cause a reader confusion because it implied that the build process has knowledge of the actual live flash partitions on the target device, which it does not.]
If you can outline how the rootfs limit is established and enforced in the make process, that might give me an angle to work on. I see a lot of variables being passed around that obviously contain the device-specific constraints, but haven't yet untangled where they originate.
Are you adding any extra settings through
Btw - I'm looking at the Wikidevi entry for your hardware and it clearly specifies 4 MB.
Did you upgrade the flash?
If not, then check what you added besides LuCI. LuCI-SSL e.g. won't fit on 4 MB flash.
Best way to check what else you have enabled is using
./scripts/diffconfig.sh. Paste the output here so we can check as well.
FIrst of all, of course, you're right - the device is 4MB not 8MB. No idea how I got that confused.
A couple of diffconfig runs showed that I had included libmbedtls from a previous config - that alone needs almost 1M installed, so it's almost certainly the culprit.
For others that may stumble on this thread and are new to LEDE, and don't work regularly with make, I didn't realize that "make defconfig" didn't fully reset the config to the default for the device. What finally worked was deleting .config entirely and starting again with make menuconfig.
Borromini, many thanks for your time and help.
Unfortunately, it still isn't working for me. This is my diffconfig:
This seems to just miss the 4MB mark and a sysupgrade image is not built. I'll see if there is something I can take out..
[SOLVED] By turning off kernel symbols and debugging options in the kernel config, this once again just squeaked in under 4MB and now works. But that was necessary in order to get the factory and sysupgrade image files to be produced by make.
Folks trying to build images for the DIR-600A1 please keep this in mind.
That makes me wonder how the release builds will go. If a default config including LuCI is too big, then that will break a lot of 4 MB devices. Will test that myself with a few TL-WR841N builds.
I ran into the same problem and I logged a bug. It means upcoming 17.01 images won't build either, so...
Ouch. Thanks for filing the bug.
I feel that the bug should also note the solution to that problem too since is related to flash size limitation ;;
EDIT: I'm not familiar with the settings for Squash file. Maybe developers can use a slightly higher compression?
What works individually is not a solution. Stripping symbols etc. impedes debugging and whatnot. Keep in mind all the ar71xx images would get stripped - this kind of stuff is architecture-wide.
I feel like this is a limitation in terms of the hardware, LEDE will continue to grow in size and LUCI will (possibly) be available only to routers with > 4MB size (especially with the new luci-ng in development - not sure how large it is)
Not to mention the linux kernel growth adds additional size to the firmware
I'm not sure anyone knows what fraction of the LEDE/OpenWRT active user base currently uses 4MB flash devices. Both LEDE and OpenWRT will need to decide how important it is to continue to support 4MB flash devices with LuCI.
Software naturally grows larger with time and features, and it takes considerable effort and planning to layer the design in such a way that only those users interested in using new features need supply the additional hardware resources. In a project defined around embracing a democratic process, this is even more tricky.
Moreover, it takes a lot of work just to make this happen -- work that takes away from other goals. At some point, the decision to sunset support for low end hardware begins to look pretty attractive.
Even the very best-run commercial software companies struggle with striking the right balance here. There is no "right" answer. In my personal experience, it does help to take a clear explicit position, socialize it among the key folks, build consensus, and accept that some people will not be completely happy with the outcome.
This is such an important thought, I am moving it to its own topic here... Thanks for bringing it up.
In this case, that's probably what breaks this specific image - as I understand it, the kernel gets a separate 'partition' apart from the rootfs. From what I can gather, for most platforms or devices this split between kernel/rootfs is static - ie the sizes don't get adjusted to accommodate a bigger kernel (even when there would be enough headroom).
Kernel symbol table info is disabled on release builds. Jow confirmed this, so there should be images for the DIR-600 A1.
Great. Looks like we dodged the bullet, at least for now
Yes, but I worry there are other packages that are deemed "essential" that'll push us over? (I have no idea whether this is true, though...)
Why there's no more images for the latest version 17.01.2 ?
17.01.1 does have images for dir-600.