flashed today build a38982e without any issues
1 Like
Also brick an AX3600 with "only" an sysupgrade from [Updated prebuilt images 2023-01-07-0009] to [Updated prebuilt images 2023-01-09-2026]
I was able to update my AX3600 today.
I came from a two-root-partition version from about 3 months ago.
For this i compiled a image from robi´s branch ipq807x-5.15-pr-final yesterday.
I proceeded as follows:
- push the
...-initramfs-factory.ubito the device viascp - flash this file:
ubiformat /dev/mtd12 -y -f /tmp/openwrt-ipq807x-generic-xiaomi_ax3600-initramfs-factory.ubi -s 2048 -O 2048 && fw_setenv flag_boot_rootfs 0 && fw_setenv flag_last_success 0 && reboot
(or mtd13 if fw_printenv flag_boot_rootfs returns 0 instead of 1)
- connect now to 192.168.1.1 (the default ip in factory state) and push now the
...-squashfs-sysupgrade.binto the device via scp. - flash this image via:
service wpad stop && sleep 8 && sysupgrade -n /tmp/openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-sysupgrade.bin
Now my device is updated to the newest version with resized single root partition.
I was also able to restore my old config.
For this i take a backup file and changed the interface names in all files inside as explained above. Then i set the compat version via uci set system.@system[0].compat_version="2.0" and was able to restore the backup via luci.
Maybe my procedure will give some clues to those who have broken their device.
3 Likes
Unfortunately no.
My AX3600 was already with new unique partition and one version from 4 days ago !
Most of reports are for sysupgrading between latest Robimarko's releases.
I did upgrade from [2023-01-07-0009] to [2023-01-09-2026] and ended up with bricked router.
1 Like
Another brick on the table here. I extended the partition from a early dec robi release with 0901 release and ended with an brick. The extention part worked nicely but the sysupgraded machine never woke up.
After tftp recovery, initramfs and sysupgrade everything ok.
Same thing here, already had migrated to single partition in 2023-01-05-2313.
Used the same procedure that @slyvan uses, it was documented by Robi.
I didn't stop wpad, because radios are already off from initramfs-factory boot, but that's not relevant.
Then I had sysupgraded to all the versions released with success, until the last one issue.
Is clear that something is happening, because all the reports are from people with robi single partition doing a simple sysupgrade with a robi single partition firmware.
If someone plans to upgrade and has serial connected, will be great. Some log is the only way to take enough info to see what is happening.
1 Like
So i updated from [2023-01-06-2152] to [2023-01-09-2026] yesterday and had no problem, i even kept the settings as i already changed the interface names ...
1 Like
This is getting quite crazy, as there was no sysupgrade changes until the version from January 9th, and since you are sysupgrading to it any recipe changes arent used anyway.
Maybe the single partition is affecting? Until now, the "official" was dual partition. Some people moved to the single partition as test, but some of them didn't upgrade or if something failed, they ignored it because it was "experimental" and maybe they did something wrong.
We tested that moving to single partition worked, but we didn't test too much that the sysupgrade worked.
It really shouldnt as every time sysupgrade is called env is set to explicitly boot from the first "rootfs" where the kernel is now, I have been using it for a while now and it just keeps on working.
It would be great to be able to catch it, as it could really be some stupid bootloader logic interpreting the environment
2 Likes
Same problem, Falshing from the second last version to the last version bricked the router. Since that was not the frist time I was able to bring it up again within an hour.
1 Like
Can you give more details?
Version numbers; How did you flash? throu luci or via command line? Which parameters? Did you check SHA256 sum, did you kept settings etc ...
Whats your environment variables ...
After I went to single partition in 2023-01-05-2313, I restored my config as described bellow:
Then i made a config backup in luci, that I still use.
Now that I think of it, when I untar my config ontop of the the deafult one in a running router, I can't be sure if any of those files were not locked, but I didn't had any errors, so I guess not.
Then all sysupgrades worked, except the last one and I still load that config, so I guess this was not the problem.
Don't know of it helps, these are the last upgrades I did:
...
bce37ee (2022-12-19-1045) -> backed up config -> ssh service wpad stop -> sysupgrade through luci keeping settings -> OK
63ba272 (2023-01-01-1759) (new network names) -> backed up config -> changed the network names -> ssh service wpad stop -> sysupgrade through luci NOT keeping settings -> upload changed config -> OK
8faba05 (2023-01-05-2313) (single partition) -> backed up config -> followed the instructions (ubiformat, sysupgrade, etc) -> upload backedup config -> OK
ef42fc4 (2023-01-08-1438) -> still compat_version warning so I set system.@system[0].compat_version="2.0" and commit -> backed up config -> ssh service wpad stop -> sysupgrade through luci keeping settings -> OK
a38982e (2023-01-09-2026) -> backed up config -> first try I forgot to ssh service wpad stop so it rebooted without the new version -> ssh service wpad stop -> sysupgrade through luci keeping settings -> NOK
Bricked router -> followed the Debricking TFTP recovery steps (only worked on lan3) -> obtained SSH with the javascript method -> followed the instructions (ubiformat, sysupgrade, etc) -> upload backedup config - ok
Never happend before, never had to recover the router, allways did the sysupgrade through luci, only problem was when I forgot to stop wpad and had to do it again.
1 Like
untar-ing rather than restoring the backup was my shortcut to avoid finding out if the restore process would reject a "1.1 compat" archive on a 2.0 compat system. I haven't done my homework on this. My gut feeling is that locks won't be a problem. I often edit most of those files in vi and bounce wifi/network/processes through init.d to activate changes, rather than using the GUI or UCI.
edit: it all looks OK, and the restore process of 1.1 conf backup should proceed on a 2.0 system even through the GUI (though you still have to manually update after).
sysupgrade -r is a simple untar too:
[ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
v "Restoring config files..."
tar -C / -x${TAR_V}zf "$CONF_RESTORE"
exit $?
1 Like
Couldn’t the changes triggered by 981213 (GitHub user) PR review from two-three days ago around platform_pre_jupgrade cause this?
Either as a bug in change or unknown side effect .
And it’s the only change around this area..
Well no as you are upgrading to that, old version doesn't have that in the recipe at all.
Its only gonna get used when sysupgrading after that version
Yes, you are right.