I did the UBI installer version 1.1.1, and then sysupgrade to latest snapshot two days ago. I tried to do an auc update today, and got this message:
Tue Mar 12 23:50:21 2024 user.info upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0).
Tue Mar 12 23:50:21 2024 user.info upgrade: SPI-NAND flash layout changes require bootloader update. Please run the UBI installer version 1.1.0+ (unsigned) first.
Does this mean I need to go through the steps again or this is just a standard message and I can proceed to force upgrade?
Well, I have updated my routers at least 4-5 times and every time, I am searching for this post. Not sure if this is fixable, else we can have it in wiki added by someone with access to it.
I used the installer 1.1.1 to upgrade a router, then flashed a copy of the snapshot that I had built and it went through absolutely fine. Everything good so far and my router is running a 6.1 kernel. I then uploaded an archive of my settings that I took before I went through this process.
Now when I look at flashing the firmware a second time to a slightly newer snapshot it tells me ...
"Image check failed:
Wed Mar 13 14:05:59 GMT 2024 upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.0->2.0). Wed Mar 13 14:05:59 GMT 2024 upgrade: SPI-NAND flash layout changes require bootloader update. Please run the UBI installer version 1.1.0+ (unsigned) first. Image check failed."
I am pretty sure this isn't right, but I am guessing that it is because some erroneous data has been carried over in my archived settings? Something I can perhaps fix in /etc/config or similar?
Thanks, I actually just managed to find the answer myself by fishing through the differences in the /etc/config files so I took the slightly harder road ...
Unfortunately with over 4,400 messages in this thread fishing through it is becoming a bit painful, but that isn't really an excuse of course ...
On the other hand I also found a few other differences such as in "/etc/fw_env.config" and "/etc/config/ubootenv" the references to "/dev/ubi0_0" and "/dev/ubi0_1" have changed to "/dev/ubi0_2" and "/dev/ubi0_3" respectively. I am not sure if this is important, but it feels like it maybe should be?
I, too, restored my settings from backup after upgrading to kernel 6.1, and it was working fine until I tried to do the first sysupgrade, now it's bricked.
Wonder if it's some other conflict from my backed up configs that caused it...
just popping back in to say that I haven't had any issues so far.
I also haven't restored from backups or flashed any snapshots since the 1.1.1 installer/sysupgrade
Sorry to bother you again. Do you know how to set up RT3200 as a Switch?
I have two RT3200s, and want to set up the second one as switch. I change the IP address on second one to 192.168.1.5 (the main one is 192.168.1.1)and disable DHCP. Seems like the second one doesn't connect to internet.
Until I get some useful logs to share from my bricked RT3200, I can at least volunteer that it was on 6.1.80 (generated & downloaded from the Attended Sysupgrade while still in 5.15) when I attempted my first Attended Sysupgrade in the new layout/kernel, and also restored previous configs as I mentioned before (applying the 2.0 compatibility flag after restoring config).
I did another round of stock -> v1.0.3 installer -> OpenWrt 23.05.2 -> v1.1.1 installer -> sysupgrade file (Linux 6.1.79) which comes with installer -> auc to today's snapshot. Looks all fine on my device which I've been torturing with [write 64kb of random stuff to flash, wait 80 seconds for wifi and everything to come up and client associates, reboot ::] loop for more than 24 hours before... I really must do something fundamentally different and the only real thing I can see is that I'm using a lab power supply (to measure consumption) instead of the original (which I can't find any more).
@daniel and any other E8450 experts-
could you possibly summarize the steps, using mtk_uartboot, to unbrick/restore to function/ an e8450? by reading the recent (2-3 weeks) flurry of actiivy about bricked/failed devices, this is a recent probelm related to the change ubi installer / mtd allocations..
i - and others - have searched these forums and there is clear series of posts that describes the steps which are necessary to recover, including which specific files and commands.
from what i can reconstruct, there are at least 4 levels of recovery possible
1 - uboot
2 - BL2
3 - BL3
4 - initramfs RAM image to ubi-written image
i'm quite certain i've made errors in this request so any help is appreciated
thank you
the ubi installer and mtk_uartboot tools are superb. thank you.
Awesome work, really glad to hear this as I'm sure many will be. So I am safe to use the installer v1.1.1 from a device currently running 25.03.2 with reboot issue?
Also afterwards is it recommended/necessary to move to the snapshot image or can I just keep it on 23.05.2?
The news is probably the new possibility (mtk_uartboot being published on March 1st) to unbrick devices -- no matter how long they have previously been sitting on a shelf waiting to be de-bricked via JTAG (which is more complicated which is why many users didn't do it).
I deliberately waited until mtk_uartboot was available before working on the updated (and more robust!) flash layout and installer. So this is not a coincidence.
The files you need to use for recovery depend on which layout was used when the router turned into a brick.
In order to simply recover the device, you always need bl2-for-mtk_uartboot.bin
Regarding FIP file to use, there are only two options:
device has already been converted to new flash layout using v1.1.x installer and yet turned into a brick already again (something which we should be able to prevent in the near future, I hope)
=> Use openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip
The syntax for mtk_uartboot is simple:
mtk_uartboot -d /dev/ttyUSB0 -a -p bl2-for-mtk_uartboot.bin -f *uboot.fip
This will allow you to boot the router once. You then have to re-write what ever was broken. As crazy as it sounds, but literally reading from the flash and writing back the read content fixes the issue. The most convenient way to do this is by starting a serial console right after mtk_uartboot and using U-Boot.
post v1.1.x
=> ubi remove rootfs_data ; ubi read $loadaddr fip && ubi write $loadaddr fip $filesize
Note that this applies of course only if what you are seeing is the infamous "OpenWrt Kiss of Death" issue with no other action taken and no other mess created by the user up to this point. Should there be more or other problems (such as overwritten/missing factory data which results in no MAC addresses and Wi-Fi calibration) you will also have to write that again. I've guided multiple users here already how to do this and I'm too tired now to go through it again. Contact me by PM and give access to the serial console e.g. using tmate, I'll fix it in few minutes after seeing what is actually broken.
The news my have sounded better than it actually is. Note that I managed only exactly once on one device to see OKD, and this was after the device had been sitting on a shelf, powered off, for a couple of weeks.
For now I would recommend you to stay on the stable 23.05 release and only re-write fip using the method described in the post above until I publish v1.1.2 installer which will contain this fix as well.
so I took the slightly harder road ...