Ever since the mvebu move to kernel 6.6 I have not been able to flash my WRT1200AC device with a new build. In trying to figure this out, I noticed the /overlay is very small and very full:
I can't figure out where the overlay partition size is set. This may not be related to the new kernel but it sure seems like something that should be corrected. The kernel and root sizes in menuconfig are correct for the models per the default config (16M and 104M) and all other models I have flash fine and have decent (30M+) /overlay sizes.
Any ideas where to look to correct the small overlay on the WRT1200AC model? TIA.
While there are currently issues with sysupgrade (I've been using -F option and the firmware image) my upgrades have only been failing to take on the caiman model. Currently I'm trying to understand why my /overlay is so small, which may be a complicating factor and I think I may have it.
Both allocate 40M for kernel partition but caiman is allocating 2MB less of that for rootfs -- I'm curious regarding the reasoning for a 4 or 6 MB difference and why the caiman rootfs allocation can't be changed to 36MB as well.
I likely need to reduce my image size, as it's approaching these values (as I'm guessing is shown by the small /overlay remaining in my original post). Bloat from using dnscrypt-proxy-v2 and openssl among others may be starting to push a limit.
The upgrade issue did not start with the 6.6 kernel push for me, but at a later point.
sysypgrade -F factory.img actually upgrades correctly for you?
Your mamba can sysupgrade correctly? This fails for me on the same target device, been using tftp or mtd.
I think this stems from the original OEM FW reservation.
Upgrade fails for me with both a mamba and rango, and as indicated in the other thread, and the issue linked, the venom also fails. Both device overlay appear OK, maybe @ghoffman could check the venom.
Yes, sysupgrade -v -F firmware.img upgrades mamba, rango and shelby (keeping config). The sysupgrade binary upgrade has been failing for some time, this is the first I've heard that it's not just a "me" problem.
I may try your method on the 1200 although I only have easy wireless access to most devices for upgrading (hence my desire for keeping config unless I absolutely can't).
I vaguely recall more memory being required for one of the kernel upgrades, somewhere in the 5.5 or 6.1 time frame. I'm wondering if I can add more room for rootfs vs. the kernel, as in the mamba version. I don't recall off-hand but the WRT1200AC may use the same wireless driver as the 3200, which results in a larger kernel.
my recollection of this issue goes bak to the original 3 mb kernel size allocation. for venom and caiman. The decision was made not to alter the mtd map because a 4 mb kernel could be allocated even though the original map had only a 3 mb. see
Originally WRT1900ACv1 had a smallish kernel partition size of 3 MB, while the later mvebu routers had 4 MB until WRT3200ACM that had 6 MB. Latest addition WRT32x then curiously had again only 3 MB.
That 3 MB proved to be too small when the kernel size grew along new kernel versions. Installing OpenWrt was impossible. So, following the example of ipq806x (https://github.com/openwrt/openwrt/commit/dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6) I proposed increasing the kernel partition size similarly for mvebu WRT1900ACv1 and WRT32x.
So, the kernel size for those two routers was increased. The remaining part left for rootfs was then naturally reduced by the same amount. So 40 = 3+37 changed to 4+36 for WRT1900ACv1 with the smaller total size (and 123 = 3+120 --> 6+117 for WRT32x with flash abundance.)
Others (already with 4 MB or 6 MB kernel size) were not touched.
Your router has still its original 40 = 6 + 34 partitions.
Yes, after ghoffman's post I began reviewing the history (crazy how easy it is to forget this stuff after a few years).
I don't think I'm pushing the limits of 4M on my kernel (for the mamba), but it appears I am pushing the limit on 34M flash space on the caiman. I was suggesting I could possibly reduce the caiman flash region to 4M, thus freeing up 2M in rootfs. However, that's still not a lot of margin and my time may be better spent working on reducing image size where possible.
I'm still missing something, as my WRT1900ACS devices have the same partitioning (6M / 34M) but the room on the overlay is about 2M greater. I'm not sure how I'm losing that room -- I don't take advantage of per-device packaging, the only overwriting that occurs is due to keeping configs. du -h in /overlay/upper shows 2.1M usage in the WRT1900ACS and the WRT1200 shows 1.4M, despite having 2M less total room. Bad flash blocks, maybe?
@InkblotAdmirer@hnyman@anomeome
for venom/wrt32x: even though the size of the kernel partition was increased to 6mb, only 4 mb was useable. i can't find the post, but some very knowledgable openwrt dev (certainly not me) stated something like "4mb should be enough for kernel size increases for a while".
the u-boot loader may not be able to load the full 6mb even if that size is set in the pri_kern_size and alt_kern_size env variables.
when i look at my wrt32x fw_printenv, i get
priKernSize=0x0600000
altKernSize=0x0600000
but when i look at the mtd map, there is only a 4mb offset from kernel to ubi:
off topic a little here - venom factory kernel from nov 2017 was 2077344 bytes! i'm tempted to reload to poke around again.
the problem i'm trying to solve is the sysupgrade issue so i'm trolling for anything related. i'll stop on this thread here.
thx