[SOLVED] Why no images generated for default D-Link DIR-600A1?

Although I've succeeded getting LEDE running on a D-Link DIR-600 with no LuCI, when I add LuCI in Buildroot, the flash images are no longer generated. I presume this means insufficient space, especially since when I tried to install LuCI from opkg it failed explicitly with "not enough space on device".

I then did a make defconfig to get what I assumed was a "fail safe" set of packages for the DIR-600, and was happy to see that LuCI was selected. But make failed to generated images even from the default config for that device.

I'm not sure what to do next. Do I conclude that LEDE with LuCI has just grown too big for this device (with 8MB Flash), and that I should file a bug or pull request in the default config for the device? Or might I be doing something else wrong?

Thanks -

8 MB should be plenty for LuCI. Re-run your build with make -j1 V=s while log the ouput and check for errors.

Many thanks for the suggestion. Here's the stderr output from make:

19+1 records in
20+0 records out
1310720 bytes (1.3 MB, 1.2 MiB) copied, 0.000683838 s, 1.9 GB/s
Pseudo file "/dev" exists in source filesystem "/home/david/lede/lede/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/dev".
Ignoring, exclude it (-e/-ef) to override.
padding image to 00250000
padding image to 00247000
padding image to 00248000
padding image to 00250000
padding image to 00260000
padding image to 00280000
20+1 records in
21+0 records out
2752512 bytes (2.8 MB, 2.6 MiB) copied, 0.0013409 s, 2.1 GB/s
1+0 records in
1+0 records out
1310130 bytes (1.3 MB, 1.2 MiB) copied, 0.00349668 s, 375 MB/s
padding image to 00390000
Warning: /home/david/lede/lede/bin/targets/ar71xx/generic/lede-ar71xx-generic-dir-600-a1-squashfs-sysupgrade.bin is too big (> 3538944 bytes)

Not sure whether padding went crazy, or what else causes 1.3MB to become > 3538944 bytes... As you suggest, it should clearly fit...

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 env/files/?

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.