Thanks, I was not sure what the buildbots use for things. The PR description left me wondering as I did not think such a thing was something done with an OpenWrt build. I do use clang-18 in my process, but believed it to be limited to just the one package of interest. At any rate I slapped a build together to test and that ain't it.
@anomeome -
i'm trying a few things with r27150 today.
as you may recall - the wrt32x default partition scheme allocates 3mb to kernel and the remainder to rootfs. 3-4 years ago there were discussions about whether to change the allocation scheme to that of wrt3200, which allocates 6mg to kernel. the conclusion at that time was that such a re-partition scheme was not needed because with a minor change in the openwrt wrt32x build, a kernel size of 4mb could probably be accomodated.
you commented on this issue in sep 2020:
recently, kernel sizes for openwrt builds have been pushing the 4mb limit - the most recent kernel size is 4,031,632 bytes.
i'm wondering if this is what's creating the issue?
Ya, I thought of that as well, but in your use of mtd above I noticed that it was the factory image in play so you should be good on that front.
Edit: Here is the resize thread
Well, in March 2021 the kernel size limit for WRT32x was changed to 6 MB, not 4 MB, so reaching the 4 MB should have no impact.
1 Like
right you are - of course!
thank you - so this is not the problem.
@hnyman @anomeome-
i've doen more testing of old build versions i could recover.
builds (ad date downloaded) in which sysupgrade works correctly both from part 1->2 and 2->1:
r26300, 6/2/24
26657, 6/8/24
26608, 6/12/24
26912, 7/10/24
26928, 7/12/24
26955, 7/17/24
builds which fail 20>1:
26775, 6/24/24
26993, 7/25/24
27110, 8/11/24
this interval from 6/24- 7/25 corresponds to kernel version commits, but also to the shift from auc to owut, and come changes to ubus calls were made as part of this. specifically,
in which @daniel and @psherman are discussing plans for ucode changes for sysupgrade, and
in which owut made it into snapshot on 6/25/24.
there was subsequent discussion about sysupgrade failing in
curiously, luci-advanced-reboot stoped being able to decode the openwrt version in the other partition during this time interval also.
so i wonder if 'something' the complex sysupgrade-ucode logic is borked for the wrt32x/venom series?
this sysupgrade issue on wrt32x has been confiormed by at least one other user in the issues git:
thanks all
to the orinal poster - this thread has been hijacked, but you should pay attention because current snapshots will likely create sysupgrade problems for you until addressed.
1 Like