I have not tried firstboot yet (because I don't have easy ethernet access at the moment), but it is something I would try before repeating the ramboot sequence.
Have you tried the "dry-run" mode with sysupgrade "--test" option?
It might give some clues.
But maybe not, as your console log seems normal, like @borromini already said.
I have ran into similar things a few times in the past dozen years, and usually the debugging requires serial console to see what happens...
...and possibly also debug "echo" statements inserted into /sbin/sysupgrade, /lib/upgrade/do_stage2 and /lib/upgrade/stage2 depending on your platform's upgrade characteristics, so that you see exactly where the flash fails.
Yes, that was the first thing I tried. Unfortunately, it did not any output at all.
sysupgrade -n did not work, neither did firstboot initially - from the CLI it said it could only delete the files as the partition was still mounted. However, I then chose "reset" from LuCI and after that was finally able to flash 21.02.1. (Recovery of the mesh network configuration was a bit of a chore as I needed to install some kmod packages the get it running, and of course that was not possible without working network connection. But it's all sorted now.)
1 Like
So it looks like being able to flash the Fritz!Repeater 3000 once does not mean much - I've created a custom build (basically same as stock with a few more built-in packages), but again flashing fails.
Any ideas if there's anything I can try to fix this once and for all (e.g. flashing the same image multiple times after the next reset)? Having to completely reset the device each time before flashing a new firmware is annoying.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.