[ 20.206604] mount_root: loading kmods from internal overlay
[ 20.266758] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[ 20.275157] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
[ 20.865937] Too few erase blocks (4)
[ 20.870784] Too few erase blocks (4)
[ 20.874646] mount_root: failed to mount -t jffs2 /dev/mtdblock5 /tmp/overlay: Invalid argument
[ 21.366593] Too few erase blocks (4)
[ 21.371095] mount_root: unable to set filesystem state
[ 21.376538] mount_root: switching to jffs2 overlay
[ 21.381516] mount_root: switching to jffs2 failed - fallback to ramoverlay
[ 0.000000] Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jffs2
[ 0.609620] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 20.874646] mount_root: failed to mount -t jffs2 /dev/mtdblock5 /tmp/overlay: Invalid argument
[ 21.366593] Too few erase blocks (4)
[ 21.371095] mount_root: unable to set filesystem state
[ 21.376538] mount_root: switching to jffs2 overlay
[ 21.381516] mount_root: switching to jffs2 failed - fallback to ramoverlay
Yeah. Only 4 blocks of 64kB free, and 5 blocks would be needed.
Doctor, can you save WNDR3700v1 then? 
Sure. I removed some more packages in master-r15404-55e23f2c02-20210102 from v1, so that v1 clearly fits below the size limit. Main removals were htop, BCP38 and ipset support.
(There aren't that many packages left in v1 that can be easily removed, so hopefully it will take some time before we again hit the limit.)
I also added a safeguard to the build logic: I decreased the allowed image size by 320 kB, so that future builds will fail if they surpass the practical size limit (of being able to create overlay and store settings).
2 Likes
Good to hear; thank you so much.
I just made the upgrade to r15404 without worry.
I looked for "failed" occurrences in the kernel log:
[ 27.589780] ath9k_pci_owl_loader 0000:00:11.0: Direct firmware load for ath9k-eeprom-pci-0000:00:11.0.bin failed with error -2
[ 27.601192] ath9k_pci_owl_loader 0000:00:11.0: Falling back to sysfs fallback for: ath9k-eeprom-pci-0000:00:11.0.bin
[ 27.613807] ath9k_pci_owl_loader 0000:00:12.0: Direct firmware load for ath9k-eeprom-pci-0000:00:12.0.bin failed with error -2
[ 27.625241] ath9k_pci_owl_loader 0000:00:12.0: Falling back to sysfs fallback for: ath9k-eeprom-pci-0000:00:12.0.bin
It seems to me that this is normal since my WNDR3700 has an architecture Atheros AR7161 rev 2
This community build from me celebrated its 10th anniversary at the end of January:
https://forum.archive.openwrt.org/viewtopic.php?id=28392&p=1
Post #1
hnyman
30 Jan 2011, 13:24I have built a rather minimalistic build for WNDR3700v1, WNDR3700v2 and WNDR3800 focusing just on the features I need. This is pretty much the basic IPv6 enabled router setup matching the WNDR3700 hardware without too much additional fancy stuff.
Much has changed during the ten years, and the WNDR3700v1/v2/3800 starts to be antiquated. But it still serves well for modest home networking needs 
4 Likes
stable openwrt-21.02
owrt2102-r15842-5808c8c6ba-20210220 (opkg package download does not work, yet)
I have built the first 21.02 build. It is almost identical to master at the moment, so this is mostly for people who want to initialize their own 21.02 build environments.
Note that the 21.02 buildbot has not been signing the package lists properly, so opkg is currently unable to download and verify package lists. This has already been fixed, but it will take 1-2 days before the correct settings have propagated.
(The package download dirs are already there, so manual downloads are possible: https://downloads.openwrt.org/releases/packages-21.02/ )
I will build 21.02 irregularly for now, and will switch the regular "stable build" to 21.02 latest when the first official rc version is released. I will then drop the 19.07 build soon after that.
1 Like
Hi,
I have an issue. I'm using OpenWrt SNAPSHOT r15520-54bfebdca0 of yours.
I see that there is a certificate generated for UHTTP by default I wanted to add this certificate to trusted using instructions here https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings. But when I issue this command
openssl pkcs12 -export -out mycert.pfx -inkey uhttpd.key -in uhttpd.crt
The response is "unable to load certificates"
I'm curious why that's happening
Nothing special related to my build, I think.
Might be key uhttpd format related. You might test with "-inform DER"
Google for "pem or der"
1 Like
Thanks 
I have one more question. Do you know if packages like kmod-switch-RTL8366S have any value for WNDR3700 v2 router which has RTL8366S switch?
To my knowledge all needed hardware drivers are already included in the default selection. (and you can't install buildbot kmods to private builds)
I installed the latest build ( master-r16077-785ab2b62c-20210303) and it seems like traceroute is broken on the Network/Diagnostics page. It only outputs:
traceroute: NO OPT x!
But it is not working on the previous build too.
I get the same error when executing from an ssh shell:
root@openwrt:~# traceroute google.com
traceroute: NO OPT x!
traceroute does not have any option -x, so I assume it has something to do with how it was compiled.
Feel free to file a bug. There is nothing special in my build.
Seems to happen also from the SSH console
ok, thanks for the quick reply!
oh, somebody was quicker...
We likely need the fix for busybox:
https://git.busybox.net/busybox/commit/?id=f3a55b306ed3803133ab028b72b255c65d94197f
Busybox 1.33 branch log shows that the fix has been backported to 1.33 branch today 
2 Likes
I made a PR about the fix
cool, thank you!