I only have a Gargoyle image (this is what I normally develop for) I can share with you. May be best to wait if you’re after Clean Openwrt.
@anomeome, @lantis1008 -
on wrt32xb:
i used your wrt32x sysupgrade image to upgrade over OpenWrt 18.06-SNAPSHOT r6984-fa0275b, which was on partition 6 (boot_part 1) from the gui. the image flashed to partition 8 ( boot_part 2). i then used your image to flash again from the gui, which put your umage back on partition 6 (boot_part 1). so i dont htink it has solved the sysupgrade problem.
Your description would indicate the correct behaviour of sysupgrade doing a flash to the inactive partition; i.e. it is a round-robin, where it flashes to the inactive partition in order to preserve your current good image, in case of a bad image/flash.
Agreed, sounds fine to me.
Also, without the fix, sysupgrade would not have run at all and you would just end up straight back where you came from.
i admit to be confused. when i asked about this behavior before, i was told that this sysupgrade pattern was evidence of the failure of the process.
i have always been able to use sysupgrade from the wrt32x gui and from the command line.
I’ll clarify again.
Sysupgrade on these devices flashes the alternate partition. If you are on 6, it flashes 8 and reboots to 8. If you are on 8, it flashes 6 and reboots to 6.
The WRT32X had an issue in its initial support commit which meant that the console bootarg was broken. Without the console bootarg, serial access didn’t work properly (unless boot interrupted and booted manually). Without the console, sysupgrade is not possible.
The latest commit should fix this.
Now it seems like you may be using a WRT32XB, which (and god I hope not) may be slightly different to a regular WRT32X. If the slight difference is that the uboot on that version doesn’t mangle the console argument, then it is entirely possible that it was working for you all along.
I doubt this, and think maybe you weren’t 100% sure what you were looking for, and missed the subtlety of a failed sysupgrade (and trust me, it’s subtle here).
By way of a cautionary note: you may want to ensure, via your upgrade methodology, to never have the exact same image on both partitions. example: If you load an image that you cannot get off of(it happened), you are hooped without a serial connection. It just breaks the failsafe notion behind having >1 partition.
@lantis1008 -
thank you
your post from a few days ago:
"5d
Yes this is what I expect to happen currently because of the bug."
i read this as a reply to my post (two above that) which described the alternating partition behavior for sysupgrade. but i thin yours was a reply to spuriousoffspring (one above that).
so sysupgrade seemed to work except for the console issue? i thought the mangled console argument was related to the syntax of the remaining arguments - exactly the boot partition argumetns -on the nandboot environment metavariable. .
sorry for confusing it more, and i appreciate your development work.
@anomeome - thank you for your builds.
I'm a bit lost in this thread.
Is the WRT32X ready for update yet? I have one that can't run upgrade - do I have to load something via the serial port or just wait for the right release and use the regular update?
From what I understand the patch to repair sysupgrade was applied to the most recent builds. If you are still on the May 18 release you have two options:
Flash factory image from stock Venom UI
Serial flash
Just to make sure I understand:
"Flash factory image from stock Venom UI" is only an option if I'm still using stock firmware?
"Serial flash" Which file do I flash from the serial console? Venom first, then factory image, or can I go direct to factory image?
Sorry, but I don't completely understand all of the options here.
If you flashed the broken “non upgradeable” image, then the OEM firmware should be on the alternate partition still.
Just do the triple reboot power trick and switch back to stock.
Then flash from there.
If you have access to serial, then just interrupt the boot, then “run bootcmd” to bring the system up.
Then you can just do a normal sysupgrade from the GUI.
These are your simplest options.
@lantis1008 -
as i mentioned earlier, i was able to flash a lede wrt32x image from the factory gui without problem. i am still not really understanding the sysupgrade broken problem,
as a possibly-related hint: before i flashed lede from the factory gui, i removed the 'silent=1' environemtn variable from the uboot environment. could it be possible that simply removing that directive would allow sysupgrade to function properly?
Possibly. But I don’t know anything about u-boot so I would only be guessing.
I don’t know what there is to not understand. It has been explained at least a dozen times now.
If you don’t understand why it doesn’t affect you, then the answer could very well be that you modified uboot beforehand intentionally or otherwise.
New Davidc502 build released today, June 2, 2018:
https://davidc502sis.dynamic-dns.net/
Thank you David C. and all who contributed!
i have wrt32x with openwrt 18.06.4 and Im trying to sysupgrade to 19.07.rc1. Im doing it in luci hard wire to switch file will go through ok but it will come backup as 18.0.6. do i have to up grade the kernal since its a rc release. or is somthing wrong with the boot process I have upgrading from 18.0 so do I have to go back to factory. thank you gor your time. sorry this is devol wrong spot
If you are sure of the device/image match up, you might have to try forcing the flash. scp (or wget) the image to /tmp and
sysupgrade -F -n /tmp/image.bin
if the GUI has a check box to Force you could try that first.
thanks for your reply Im not sure that the images do match you match up the sha right. Im not quit sure Ive had this issue with DD-WRT thing I remember is I had DD-WRT both partions I supect this is my problem I will try tommarow. thanks for the help.