Final update, trunk r39900 did NOT retain settings after a reboot.

There is one big difference which sticks out like dogs balls between the 2 builds.

r39800 uses a different GCC.

[    0.000000] Linux version 3.10.32 (adamk@jupiter) (gcc version 4.6.4 (OpenWrt/Linaro GCC 4.6-2013.05 r39792) ) #1 Thu Mar 27 21:06:12 EST 2014

r39900 uses the newer GCC

[    0.000000] Linux version 3.10.32 (adamk@jupiter) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.01 r39899) ) #1 Thu Mar 27 22:59:57 EST 2014

If that is indeed breaking the overlay setup then it could potentially be somewhat challenging for the devs to resolve without breaking other stuffs.  I could be wrong in that it may not be the newer GCC breaking it, but seems a bit too much of a coincidence that with that upgrade it breaks the overlay setup for NAND flash devices.

(Last edited by AdamK on 27 Mar 2014, 13:48)

Try compiling 39900 using the older 4.6.4 GCC. I haven't done it in a while but I'm pretty sure from buildroot menuconfig you can pick what version of GCC you want to use (might be under advanced buildroot settings or something like that). Then recompile the image and see if things work or if it's still broken. That way you can tell for sure if it's caused by GCC or some other commit between 39800 and 39900.

I can't be of help with testing here right now, because no buildbot and no time (maybe this weekend), but I've got a little bit of advice.

If you've already identified two commits (one bad and one good) then I'd recommend checking out the sources using git and running "git bisect". That may be a little bit cumbersome, but it's still a lot easier than picking commits by hand trying to find the culprit.

Great suggestion.  It's under advanced options (for developers) then toolchain options.  Never even thought to look for such an option, but you're right, it's in there even with the current trunk.

Am building now, will report back in a few hours as to its success.

Hi, AdamK, I tried building latest truck revision r40295 using 4.6 GCC and the result is no good. Settings do not stuck. So it's probably not due to the GCC version.

BTW, could you tell me how to checkout a specific revision from git?

Hi d1no, I tried too and it did not work so seems it isn't the newer GCC afterall.  However when this bug appeared and when the devs upgraded the GCC were at around the same time (i.e. within 100 versions in trunk)

I use SVN to checkout the source trunk.  Not sure on how to checkout a specific version in git.  In SVN the syntax is svn co -r 39800 svn://your.sourcecode.tree.trunk.here

That will check out revision 39800.

Thanks for the reply, AdamK. Since I have some spare time, I'll try to narrow down the revisions between which the problem occurs. Hope it's something simple enough even I can fix and test.

Well I compiled revision 39850 and it all works.  So that narrows it down to 50 revisions maximum where the break occurs.
That's a much better number of revisions to look at compared with hundreds of them.

Easy. After having cloned the repository you'll end up in branch "master", which is git-speak for trunk (sort of).

In git, there are no revisions, but commits and their hashes, but because this repo is a direct mirror of the svn, each commit has a message indicating its revision in svn (git-svn-id).

For a bisect run:

$ git log

now hit forward slash, type "trunk@39850"
copy the commit hash (bd4880e204ac4f777c3bbfd33f8d362243773268)
hit "q"

You've now got a last known good commit at the revision that's been reported as working above.
Now we'll do a bisect run.

$ git bisect start
$ git bisect good bd4880e204ac4f777c3bbfd33f8d362243773268
$ git bisect bad HEAD

Now you're in bisect mode.

Git will tell you something along these lines (should be exactly the same):

Bisecting: 75 revisions left to test after this (roughly 6 steps)
[cd77103c4a2da560ca0728f294beb33111015c5b] libpolarssl: add missing dependency (#15321)

This means you'll have to test about 6 builds starting with this one.
Just compile right now, flash the image and you're done.
If the image is good, git picked the right spot, if not it will go the other direction. It boils down to either

$ git bisect good
$ git bisect bad

which will yield, e.g.,

$ git bisect bad HEAD
Bisecting: 75 revisions left to test after this (roughly 6 steps)
[cd77103c4a2da560ca0728f294beb33111015c5b] libpolarssl: add missing dependency (#15321)

If a state doesn't compile (e.g. git picked a commit somewhere between depending ones):

git bisect skip

Once you're done, git will show you the culprit, you can then reset the branch via:

git bisect reset

If it's a single commit without loads of dependencies you could event revert it:

on HEAD of branch master (i.e after git bisect reset)
git revert [revision]

Yes, git is so unbelievably much more fun than svn

(Last edited by alexhofbauer on 28 Mar 2014, 09:18)

Hi alexhofbauer, thank you so much for the details about how to nail down the problematic revision in the git way. I guess it's alot efficient than doing in the svn way. I'll definitely give a try in the git way.

I'm using git bisect to pin down the first bad revision. r39874 is good.

That's awesome!  Guess I should stop being so old school and spend more time learning git.

And r39890 is good.

The final result using git bisect is as below, r39895 is the bad commit while r39894 is the latest good revision. The new fstools package is highly suspicious.

72ca3bfc401a4f1b695dcc86640dddee62716cea is the first bad commit
commit 72ca3bfc401a4f1b695dcc86640dddee62716cea
Author: blogic <blogic@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Date:   Wed Mar 12 19:32:51 2014 +0000

    fstools: add the new fstools package

    Signed-off-by: John Crispin <blogic@openwrt.org>

    git-svn-id: svn://svn.openwrt.org/openwrt/trunk@39895 3c298f89-4303-0410-b956-a3cf2f4a3e73

Indeed. There are only two commits related to that new package. No idea, whether it needs activating or is simply bugged. Default config seems to have it picked up.

Anyway, reverting these two commits might result in a working image. Might.

(order is important, they would conflict otherwise)
git revert 29219f
git revert 72ca3b

I doubt that it will build though. Will have to check this weekend, I'm really curious whether I can get a working image.
If reverting doesn't help, just checkout master @ 5b6428 and test if this build works. If it does, maybe we should file a bugreport.

(Last edited by alexhofbauer on 28 Mar 2014, 18:02)

So is there a working image yet? I'm thinking of buying on of these bad boys...

You're not much of a reader, right?

You're right.

Then do yourself a favour (if you buy a wndr4300), and stay away from OpenWRT as long as there are no officially released images.

Back on topic: Just had some time to compile r39984 (that revision right before fstools were introduced), works fine here.

Now off to the weekend.

Looks like somebody's already working on the problem:
https://www.mail-archive.com/openwrt-de … 22701.html

Read the comment before the patch; it specifically states the problem is that fstools does not detect UBI partitions on NAND properly, which is exactly what is needed/being used on this device.

Might be worth somebody grabbing that whole patch and applying it to latest trunk, see if it helps.

If you're after a compiled image that has most features out of the box I do those for another forum I am a part of.  I posted the 39800 build here:

http://forums.whirlpool.net.au/forum-re … 2239979#r2

Will build 39894 and post it on there in a few hours.

Thanks for the info. It seems devs are working on it and a solution is within 1-2 weeks. I'll just wait for the smart people to figure it out :-)

Hi, AdamK! Thanks for your work! I have downloaded your r39894 firmware , and try to flash this image directly from the stock Netgear firmware for WNDR3700V4. But it reports that the firmware is incorrect. (But the firmware for WNDR3700V4 built by rpsoft can be flashed successfully!) I find that r39894 firmware is built for WNDR4300 not for WNDR3700V4, could you build firmware for WNDR3700V4 and share it in this post for us? Thank you!

(Last edited by min_x91 on 30 Mar 2014, 02:11)

Yes that is correct the image I built was for the WNDR4300 and NOT the WNDR3700v4

I'll build an image for the WNDR3700v4 and post it up sometime today.  As per the thread on Whirlpool forums, the images I build are pure OpenWRT but have most functionality out of the box.  They are also heavily focused on IPv6.  It gives dd-wrt a good swift kick in the pants in the IPv6 department since they simply just don't seem to be supporting it in any of their builds.

So my builds hopefully make it easier for the less experienced users to try out, as well as supporting IPv6 as much as possible.