That's the generation of the upgrade image, not the upgrade script. The upgrade script is on the file system in /lib/upgrade/platform.sh and is executed for installing the upgrade:
And especially for MSTC IODATA devices (this is what I meant before with similar to the IODATA devices):
What I like best is the following approach:
run zyxel_mstc_upgrade_prepare (yet to be developed), which then
checks the current active partition
if RAS2 is active, copy RAS1 to RAS2, effectively overwriting the current initramfs system
set RAS1 as active image
set bootmenu_delay=3 in U-Boot to be on the safe side
flash to RAS1
If RAS1 was currently active, RAS2 is kept as-is and flashing continues.
That way, we preserve any OEM image that was previously installed and subsequent OpenWrt upgrades boot from RAS1 anyway.
I was wondering something because I have not tested this (I should):
If I flash through OG UI the inibooramfs image, it reboots into OWRT.
If I then plug off the device without any further operation, what happens exactly?
It may reboot into OWRT again?
It's rebooting into a initbootramfs, right? so theorically it doesn't have any persistence?
PS:
I would set bootmenu_delay=5. It's very hard to pick it sometimes even with 5.
Exactly. It's then OpenWrt but without persistence. That way, it doesn't matter which partition it is installed to as it does not have to look for a root file system.
Hard? I'm pretty sure that mine is set for 3 and it now has a countdown of 3 seconds. Any cursor key interrupts the timeout and moves to the next menu position. I was tempted to set it to 1 ...
Can you plug in the device with the USB TTL connected to PC?
In my case, if I have USB TTL connected, device doesn't boot.
To boot I have to
Plugin in the device
Quickly, put the USB on the USB port
Open the serial terminal.
In 3 seconds, it's hard to achieve. In 1 second is completely impossible. In fact, I've been leaving the thing to boot into OG firmware failsafe mode and then reboot from there, to make it easier.
In Fedora I can leave the serial waiting for input but still I need to plug the USB TTL before I plugin the router. So in 3 seconds it's fairly easy to make it. But in Windows is a pain in the ass.
Yes EXACTLY, mine is a CH340 the first usb serial I snapped on Amazon a while ago, and it works great with my Tasmota/ESPHome crappy devices
And this is the reason it should be at 5 seconds for the boot time, otherwise it's almost impossible to get there on time (and still on 5 secs it's pretty tricky if I don't put the USB on time)
By the way @hecatae also reported this behavior a time ago for a similar router. He did a even more trickier stunt to fool the issue: he disconnected GND and plugged it back after powering the router. I found that just not plugin the USB was simpler. Now here you have the solution to the issue
PS: Maybe I can snap a FT232RL that I find on Amazon relatively cheap also, may it work better?
I just updated the PR and code to automatically take a backup of the firmware partition in case we would overwrite all copies of the stock firmware during installation. The installation is now simplified to flashing the -initramfs version from the stock GUI and once booted run sysupgrade with the -sysupgrade version. The rest is taken care of by the sysupgrade mechanism.
First of all thanks for the supporting this nice affordable new device. I flashed one device with the debug/sysupgrade page. The only hickup was to notice the renaming of the -initramfs-recovery.bin image. I'm using 802.11s and batman, no problems so far. What kind of speed can we expect ?
Consider that this device only supports VHT80 so expect, at most, around 600Mb/s. Don't have immense expectations. For $25-30 we cannot ask for anything better (almost 4 times more I spent some years ago on a DIR-882, and it's much worse).
Personally, I only saw this device interesting just because it almost cost me the same as a Low cost Wifi N device which was my first idea (I bought a pair of tl-wr841n thinking I could mod them to fulfill my needs but just 4/32 is not enough, and not even supported by main branches of OWRT). So basically this router is completely nuts, unbeatable in price (you have to get it on a budget though, like most routers recommended in this forum, like Belkin RT3200 and Dynalink WRX36, otherwise none of them are that awesome). I have two separate WiFi, one for IoT and one for regular and work use and this router is simply too much for this purpose. It's like 3 times more I would expect for that use.
But I would not use this router as a daily driver, unless I didn't have big requirements. Personally I would opt for Dynalink WRX36 or a Xiaomi AIOT AC3600 otherwise. Also we don't have to forget that this router is almost comparable to ASUS RT-AC53 which I was about to buy a couple, for double the price (so currently I would only have 3 units, instead of the 6 ZyXEL I have)
PS: I still have to run many tests, but suddenly, a ton of work has come to my life Let's see if some others start commenting back on their experience.
Two first machines done succesfully. The third machine does not boot the flashed owrt sysupgrade but boot the oem fw instead. Are there some env parameters to be set before the sysupgrade ?
Hm, interesting. The boot partition is not selected using env variables but by a flag set in the "persist" partition. A script inside the sysupgrade handler should take care of that (and it has already run, since bootmenu_delay is set to 3 (the default is 0).
Could you run the following command to check what it is currently set to:
hexdump -s 4 -n 1 -e '"%x"' /dev/mtdblock7
(I hope that /dev/mtdblock7 is the persist partition, I have no device at hand to verify that right now)
Ah yeah, it could be the quotes, I copied it from the script.
That indicates that it's set to boot from partition 2, i.e. the initramfs firmware you are currently running- good.
Do you have the chance to attach serial console to the device?
It would be interesting to know what goes wrong during the flashing procedure - I assume that it succeeds in setting the partition to the first one as it reboots to stock but then fails to flash the OpenWrt image - or it fails to create the backup, that would have the same effect. Unfortunately, it disconnects the SSH session and shows these messages only on the UART console.