I'm currently using OpenWRT 19.07.0-rc2 r10775-db8345d8e4 on the primary partition of my WRT32X. The primary partition is working fine, I'm just wanting to upgrade to a newer release of OpenWRT. Upon trying to do so (using the factory image) from either the CLI or LUCI, the secondary partition that the firmware was flashed to is unbootable. I'm not entirely sure where else to go from here. The unit will appear to boot up on the secondary partition with the firmware on it, and it even obtains a IP address on the WAN interface, but all I can do is ping the address, the unit doesn't respond to HTTP/SSH requests, and I'm forced to do the 3x power switcheroo to get back to the primary partition..
Does anyone have any ideas why this is going on? I've tried a couple of different builds, OpenWRT and Divested-wrt, both of them are experiencing the same issue.. not sure if any details anyone might need, but here is the output of fw_printenv..
EDIT: Some more details might need to be in order, after looking at the output of the command I ran. Some time ago I had to debrick this device, and appears it may have been flashed with the flat image, I'm not sure if this is the cause of the secondary partition being messed up.. but alas, I'm not sure how to recover from it if it is the cause..
But as OpenWrt sysupgrade uses the boot_part to decide where to write, I think that the current firmware would actually be overwritten. (as bootcmd says partition 1, so flash to 2, but OP is actually running altnandboot = 2 = current)
The active roofts should be "ubi", so likely you are running from 1.
Sysupgrade (without settings) to 19.07.x might work.
Then you should have those two u-boot variables again in sync.
I suggest that you sysupgrade to 19.07.10, so that you should have 19.07.9 in the current one and 19.07.10 in the other one. Then you should be able to see if you can successfully run from both partitions.
Finally, due to the kernel size change, you need to later use the factory image (without keeping settings) for upgrading to 22.03.2
Ps. you might also test luci-app-advanced-reboot to see the versions on the partitions.
Pps.
other option might be to manually aling the bootcmd and boot_part with fw_setenv
Doing a sysupgrade with the factory image of 19.07.10 unfortunately yielded the same results.. The LEDs a show it successfully booting but it's like nothing is installed on the boot partition
Ok, I'll give that a shot next and let you know my results.. My intention has sort of been up to this point to keep the 19.07.0-rc2 install around, at least until I can get something stable installed. Would it be ok to flash the stock firmware, boot back into the OpenWRT install that I have, then upgrade from there? Or are we thinking something is just flat out wrong with partition 1 that's causing issues with flashes to partition 2?
from working openwrt firmware flash stock firmware. boot the router with stock firmware, flash openwrt factory.bin. leave one partition on stock firmware, so everytime you ll change openwrt version, you ll flash the new version from stock firmware, always factory.bin
since it shows that 19.7.10 is in the second partition:
when you now try use either luci advanced boot or button powercycle (see w32x wiki, 3x turn off/on), to reboot to partition 2, are you then able, to successfully boot up 19.07.10 ?
Ok, so this is kind of embarrassing... for whatever reason when you flash the new firmware on these devices, the wifi interfaces default to disabled. After having hardwired myself to the device and turning them on, everything is fine.. I was able to upgrade to 19.07.10 which is what I'm currently on and is at least a start.. I attempted to upgrade to the latest version with the kernel size update, but it seems to boot loop back to the stock linksys firmware. Haven't done much testing since I was at least able to upgrade to a normal firmware version.. I'll do some more testing to see if I can get on the latest. Thanks all for the assistance with this..
I suppose one last question... when I plan to upgrade to the latest release, am I able to use the upgrade utility in Luci using the factory firmware image of Openwrt? Or should I be flashing the newest release through the stock firmware? Currently my setup is this:
in a regular non broken state, flash on any dual partition device starts from the active partition and will overwrite the other inactive partition and will then switch the boot pointer to the other partition.
you can though choose the active partition before you start flashing.
In a regular situation on any device:
vendor firmware-> OpenWRT: factory image
OpenWRT-> OpenWRT: sysupgrade image, in regular situation
OpenWRT-> OpenWRT: factory image, in case where partition changes need to be performed and when the device is supported for this (Linksys WRT* does support, v22 was such are rare case, and you are not supposed to keep setting when doing)
Its more complicated, your case was special, due to the broken boot pointer, this is not the norm.
Basically you had several special challenges:
fix the defect partition boot selector pointer, which prevented you to update (that pointer is stored in yet another partition), any combination of 2 successive working flashes on dual boot devices hopefully fixes it.
deal with the kernel partition size change, which is a specific task for that device when moving a partition to v22 the first time, mandatory requiring the factory image to be used once per partition
deal with DSA switch driver change, this required you not to keep v19-settings (DSA was introduced in v21 for that device)
the defect partition pointer was an additional challenge in your case: might have caused the active partition to become flashed in some cases instead of the inactive. So outcome was unpredictable.
the alternate partition was in addition likely broken, when you started, so any flash activity was also risking to do changes to the device without having a working fall back partition
it was not really clear, how the vendor image would have behaved in that broken pointer situation. You might have ended with 2 broken partitions, then having to deal with a serial connector cable, to revive it.
also: coming from 19rc2 probably probably wasnt tested a lot to face the mentioned changes introduced in v21 and v22.
Thats why starting with v19.7.10 was probably the less riskiest activity, to first get the pointer fixed.
Since the pointer is now fixed, dont worry about future updates (unless the pointer gets broken again for reasons unknown to me).
