In this case you can use the firmware selector to customize the initial config, but it’s clearly too late for that now.
Hi there,
anyone knows how to revert to the stock firmware?
The last avaiable snapshot is so awful and i'd like to be back on the original OS.
I didn't find any kind of guide that explain how to do it...
There's no guide as no one has reported the success (or failure) to revert yet. Should be something like:
fw_setenv CheckBypass 0
mtd -r -e Kernel write <OEM-backup-image> Kernel
If you don't have a backup, using the bin file from Zyxel update packages should be equivalent. If you do try it, please let us know how it went.
3 Likes
Awsome! It worked like a charme!
Thank you so much mkrle!
2 Likes
could you tell us what you found unpleasant about the last snapshot, just to understand the issue behind the problem.
when you switched to Openwrt you run (from table hardware support Openwrt):
Copying OpenWrt to the recovery partition
Verify that you are running a working OpenWrt recovery image from flash
ssh to root@192.168.1.1 and run:
fw_setenv CheckBypass 0
mtd -r erase Kernel2
Wait while the bootloader mirrors Image1 to Image2
I'm wondering if anyone managed to setup failover WAN with mwan3 for this router?
I'm new to OpenWRT and installed it just to have a backup connection when primary ISP goes offline (this happens quite often).
Here is how I setup my interfaces:
Any inputs are appreciated.
May I ask what is the purpose of this step? I just installed the recovery image (from Zyxel's web interface), then logged into it and flashed the sysupdate image. It has been working for days, and I have rebooted it several times with no issues. What am I missing, if I do not copy it to the recovery partition? Thanks!
1 Like
The detailed description is under "Notes on the OEM/bootloader dual partition scheme" in this commit message:
Notes on the OEM/bootloader dual partition scheme
The dual partition scheme on this device uses Image2 as a recovery
image only. The device will always boot from Image1, but the
bootloader might copy Image2 to Image1 under specific conditions. This
scheme prevents repurposing of the space occupied by Image2 in any
useful way.
Validation of primary and recovery images is controlled by the
variables CheckBypass, Image1Stable, and Image1Try.
The bootloader sets CheckBypass to 0 and reboots if Image1 fails
validation.
If CheckBypass is 0 and Image1 is invalid then Image2 is copied to
Image1.
If CheckBypass is 0 and Image2 is invalid, then Image1 is copied to
Image2.
If CheckBypass is 1 then all tests are skipped and Image1 is booted
unconditionally. CheckBypass is set to 1 after each successful
validation of Image1.
Image1Try is incremented if Image1Stable is 0, and Image2 is copied to
Image1 if Image1Try is 3 or larger. But the bootloader only tests
Image1Try if CheckBypass is 0, which is impossible unless the booted
image sets it to 0 before failing.
The system is therefore not resilient against runtime errors like
failure to mount the rootfs, unless the kernel image sets CheckBypass
to 0 before failing. This is not yet implemented in OpenWrt.
Setting Image1Stable to 1 prevents the bootloader from updating
Image1Try on every boot, saving unnecessary writes to the environment
partition.
Keeping an OpenWrt initramfs recovery as Image2 is recommended
primarily to avoid unwanted OEM firmware boots on failure. Ref the
warning above. It enables console-less recovery in case of some
failures to boot from Image1.
Also, search "dual boot" in this topic for another AFAIK untested option.
3 Likes
This isn't entirely correct for newer firmwares. ZyXEL started using another scheme at some point after I wrote that. Now they use the two partitions in an active/backup mode, with a switch on every upgrade.
2 Likes
I think that:
and
responded very well.
for (Maybe I expressed myself incorrectly):
I just wanted to know if he had perhaps performed this step when he installed Openwrt ?
1 Like
I guess that means that the ZyXEL part of the bootloader already supports this scheme and that they simply started using it via firmware setting different NVRAM vars? I'm curious as I haven't seen images other than Kernel type in the update files for this model.
1 Like
if I remember correctly you performed this part, and therefore the bootloader should have copied the "Kernel" partition to "Kernel2"
1 Like
Yes. Turned out the bootloader checked the BootingFlag variable to figure out which partition to boot from. But this variable wasn't set by the first NR7101 firmware versions. So I didn't know about it untl ZyXEL started using it on upgrades.
Funny thing is that those first OEM firmwares didn't expect it either. They would get really confused if they ended up running from the second partition. They booted fine of course, just like they would have if that was a result of a rescue failover, but upgrading was not possible. New images would be installed to the first partition without changing the BootingFlag variable. So the router never booted the the newly installed image.
2 Likes
can the bootloader handle a tftp server similar to this (obviously it's just a recovery system hopefully cataclysm-proof) ?
How can I change the bootloader configuration to do this:
for example that it listens for 10 seconds (at boot, on an IP address that is not common with the main private networks ex:10.10.10.123) if an image file is passed to it and writes it to the partition
after 10 seconds, execute the image present on the "Kernel" partition
ps I know it would prolong the boot but it is assumed that the router is not turned off and on frequently
find this into oem dump
strings copy_mtd0.bin | grep U-Boot
U-Boot 1.1.3 (Mar 18 2020 - 14:54:49)
U-Boot
go back to U-Boot command line
UbootVer=U-Boot 1.1.3 (Mar 18 2020 - 14:54:49)
strings copy_mtd0.bin | grep "=10.10"
ipaddr=10.10.10.123
serverip=10.10.10.3
ipaddr=10.10.10.123
serverip=10.10.10.3
You need to open the router and attach serial console to be able to use tftp recovery, and that works only if you have previously set DebugFlag to 0x1. I had to do that during the development process and I can confirm that it works.
An alternative would be trying out zycast.
so you can't change u-boot configuration even with the package:
obviously after installing Openwrt on your device
You can, but I don’t think it’s possible to enable tftp recovery that way.
1 Like
ok, it was just to understand if it made sense to also install this package to test this functionality
The package should be included by default, it provides fw_setenv and fw_printenv that are used to set those nvram variables for the bootloader.
1 Like
sorry I didn't notice 