Archer A7 v5 21.02.1 settings don't survive reboot

I installed 21.02.1 factory on a new US Archer A7 v5 (back says v5.8) that was running TP-Link stock 201029 out the box. Installed using the TP-Link UI (given wiki said TFTP is not required for this version).

After the install everything seemed to be fine except none of the settings survive a reboot (password and everything is gone on reboot).

I see in the logs:

jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
jffs2_build_filesystem(): unlocking the mtd device...
jffs2_build_filesystem(): erasing all blocks after the end marker...

a whole bunch of these
jffs2: Newly-erased block contained word 0x1e4a3c6b at offset 0x00940000

Then this:

jffs2: notice: (2363) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
daemon.notice procd: /etc/rc.d/S95done: cp: can't create directory '/rom/overlay/upper': No space left on device
daemon.notice procd: /etc/rc.d/S95done: cp: can't create directory '/rom/overlay/work': No space left on device
daemon.err mount_root: failed - cp -a /tmp/root/* /rom/overlay: Not a tty

From a search this seems consistent with a device that ran out of space (like those with 4MB flash), but isn't the Archer A7 v5 16MB?

df -h output

Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                    60.3M    240.0K     60.0M   0% /tmp
tmpfs                    60.3M     72.0K     60.2M   0% /tmp/root
overlayfs:/tmp/root      60.3M     72.0K     60.2M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock5            9.3M      9.3M         0 100% /rom/overlay

cat /proc/mtd output

dev:    size   erasesize  name
mtd0: 00020000 00010000 "factory-uboot"
mtd1: 00020000 00010000 "u-boot"
mtd2: 00ec0000 00010000 "firmware"
mtd3: 00200000 00010000 "kernel"
mtd4: 00cc0000 00010000 "rootfs"
mtd5: 00950000 00010000 "rootfs_data"
mtd6: 00020000 00010000 "info"
mtd7: 00050000 00010000 "config"
mtd8: 00010000 00010000 "partition-table"
mtd9: 00010000 00010000 "art"

I tried installing 21.02.1 factory again using TFTP, although upload goes through 100% every time nothing changes. Then I tried 21.02.0, 19.07.8, TP-Link stock 201029, 190403, 19.07.7, 210519, 211022, 201120. Every time the upload is successful but nothing changes. From a search it seems there may be some version check in TFTP, so even if upload is successful, doesn't mean it installs. It seems there needs to be a UART connection to see a log of error messages and I'm not about to take the router apart and soldering to get access to that. I found talk about stripping headers from stock firmware, but it was not clear if it was just for sysupgrade or if it helps TFTP install, nor were instructions clear what to strip out.

I also tried sysupgrade through the UI and ssh (using the sysupgrade version) 19.07.8, 21.02.0, 21.02.1, both with and without the -n option, but it doesn't seem to change (no errors but router still stuck in same situation). Even tried mtd -r write with 21.02.0 sysupgrade onto firmware partition, but again it changes nothing even though no errors (although ssh disconnects so can't see any of messages).

This is not the first A7 v5 I installed OpenWRT on, I installed 19.07.7 successfully previously a few months ago on another that was updated to stock 20210125 (UI install failed, but TFTP worked fine). I have another one still in box that I plan to also install OpenWRT, but I don't dare to proceed until I figure what went wrong with this one.

I'm stumped on how to proceed. Ideally I hope to figure a way to return to stock and try again, but if not possible, at least get the settings to survive under the current situation (or with an older version of OpenWRT).

Download the stock firmware.

Download TFTP64.

Rename the downloaded firmware file to ArcherA7v5_tp_recovery.bin, and place it in the same folder as TFTPD64.

Open your network settings in Windows, and select the wired adapter (don't try this on a wireless connection).

Right-click and select Properties.

Select Internet Protocol Version 4 (TCP/IPv4) and click on the Properties button.

In the General tab, select the radio button for Use the Following IP Address.

Enter 192.168.0.66 for the IP address.

Should default to 255.255.255.0 for the Subnet Mask.

Turn the router off.

Make sure nothing else is connected to the router, it should be just the router and your computer.

Open TFTPD64. You may be asked to allow it through the firewall. Select Public.

Go to Settings > Global, and uncheck everything except TFTP Server.

Go to Settings > TFTP. Select None for TFTP security. Uncheck Option negotiation, and enter 192.168.0.66 in the Bind to this IP address drop down.

Go back to the main window, and make sure the Current Directory dropdown is showing the path to the TFTPD64 folder, which should also contain your recovery firmware file ArcherA7v5_tp_recovery.bin

The IP address 192.168.0.66 should be displayed in the Server Interface dropdown. If not, select it.

Go to the router and press the power button and the reset button at the same time.

Release the power button...but continue to hold the reset button for about 4 or 5 seconds, then release.

You should see a progress bar going across the TFTPD64 screen (although it should only take a very short time).

View the log. It should show 100% transferred.

Go back to your wired network adapter, and change the radio button back to Obtain an IP Address Automatically.

Try to access the router GUI. The stock firmware IP address is 192.168.0.1 and admin/admin for the User Id and Password.

If you can see that you have Internet access in the Network icon, but can't access the GUI, open a Command prompt and run ipconfig /release and then ipconfig /renew.

Try to access the GUI again.

The TFTP process you documented was the first thing I tried. It uploads successfully every time (all blocks sent, no resend), but there is no change after it automatically reboots. I'm guessing there may be some kind of verification going on, but no way to know without a serial connection from what I searched.

I have successfully done such a process in a previous Archer A7 before (as mentioned above), but it doesn't seem to be working for this one.

Try holding the reset button until the WPS light comes on.

Screenshot 2021-12-04 233441

It can also take 2 to 3 minutes to complete the flash.

There is also a note on the A7 V5 wiki page that says to rename the stock firmware ArcherC7v5_tp_recovery.bin for TFTP...

Yes, I know the entire procedure. I hold the button until it lights the WPS light, then upload proceeds. I also renamed the firmware file as per those instructions (upload doesn't happen unless you do so). The TFTP upload is not the issue, it completes successfully every time. This issue is the firmware is not updated after the upload. After it reboots on it own, it boots back into Openwrt 21.02.1 with the same issue of settings not surviving a reboot. I have tried a bunch of firmware versions (including multiple stock and multiple OpenWRT versions).

From a search, it is not uncommon. For example in below thread, Openwrt can't be installed via TFTP after it is updated to a too new stock firmware version (have to install older version before installing openwrt). The TFTP upload is successful, but the router refuses to install the firmware, if you look at the log in UART. Problem is UART access is only possible by taking apart the router and soldering.

I wonder if this issue is from installing 21.02.1 from the TP-Link UI or if something in 21.02.1 changed vs 19.07.7. Just hoping if anyone had similar experience can point to a possible solution (maybe with a header modification to bypass any checks during TFTP process).

If reverting to stock is a dead-end, at least I want to somehow just fix the current installation so settings survive a reboot or to revert to a older version of Openwrt. I have full access to Openwrt UI and also via command line in ssh. I'm just not familiar with Linux partitions and MTD so don't know how to go about fixing the situation via command line.

Yep...I understand that.

I had a similar situation recently with a C7 V2, and had to do a serial recovery.

Previously worked every time using TFTP, until it didn't.

See the Soft Factory Reset and Hard Factory Reset options in this wiki article.

First thing I'd try is use sysupgrade to install the sysupgrade image of the same version OpenWrt. It's unlikely to change anything but worth trying.

In the past (on other, but similar models) this inability to format the jffs filesystem has happened after TP-Link switched production to a different brand of flash chip, and the OpenWrt driver was not set up to write to the new type of chip.

Here is the boot log of my A7v5 on 21.02.1 detecting the flash chip.

Tue Nov  9 01:55:08 2021 kern.info kernel: [    0.350831] spi-nor spi0.0: w25q128 (16384 Kbytes)
Tue Nov  9 01:55:08 2021 kern.notice kernel: [    0.355854] 7 fixed-partitions partitions found on MTD device spi0.0
Tue Nov  9 01:55:08 2021 kern.notice kernel: [    0.362424] Creating 7 MTD partitions on "spi0.0":
Tue Nov  9 01:55:08 2021 kern.notice kernel: [    0.367393] 0x000000000000-0x000000020000 : "factory-uboot"
T

If you see a chip type other than w25q128 and/or an error message that may be the problem.

TFTP recovery occurs entirely in the bootloader. OpenWrt does not change the bootloader, so a history of installing any version of OpenWrt would not affect TFTP recovery capability. Installing different versions of factory firmware may replace the bootloader.

Thanks, I'll look over those in more detail and see if I can figure something out there. I did previously try failsafe mode and then firstboot to see if it fixes things, but didn't.

Thanks for the response and some references to compare. I feared also this was an issue with an unknown flash chip change among different batches, but luckily the flash chip appears to still be the same (or at least the router thinks it's the same).

Sun Oct 24 09:01:47 2021 kern.info kernel: [    0.350599] spi-nor spi0.0: w25q128 (16384 Kbytes)
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.355630] 7 fixed-partitions partitions found on MTD device spi0.0
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.362201] Creating 7 MTD partitions on "spi0.0":
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.367169] 0x000000000000-0x000000020000 : "factory-uboot"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.373807] 0x000000020000-0x000000040000 : "u-boot"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.379818] 0x000000040000-0x000000f00000 : "firmware"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.388540] 2 uimage-fw partitions found on MTD device firmware
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.394696] Creating 2 MTD partitions on "firmware":
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.399842] 0x000000000000-0x000000200000 : "kernel"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.405764] 0x000000200000-0x000000ec0000 : "rootfs"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.411756] mtd: device 4 (rootfs) set to be root filesystem
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.419386] 1 squashfs-split partitions found on MTD device rootfs
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.425828] 0x000000570000-0x000000ec0000 : "rootfs_data"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.432275] 0x000000f40000-0x000000f60000 : "info"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.438103] 0x000000f60000-0x000000fb0000 : "config"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.444133] 0x000000fc0000-0x000000fd0000 : "partition-table"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [    0.451057] 0x000000ff0000-0x000001000000 : "art"

As for bootloader being changed, the thing I fear is that using the TP-Link factory UI to install OpenWRT does change the bootloader, making this irreversible using TFTP (basically it can only load things into ram every time). I'll try maybe some more versions of stock firmware and see if I can get any version to stick (maybe going from oldest one in 2019 all the way down the list, luckily internet archive keeps a record of the links).

If that doesn't work, I'll try to do some more research into mtd partitions and try to figure something.

I have also same issue any suggestion for this so please reply. Thanks in advnace.

Did you also update via the TP-Link UI? Do you remember what stock version you updated from?

As an update, I tried TFTP on all the versions of stock firmware I can find using internet archive (from 190403 all the way to newest 211022, total 11 versions). The same problem persists (TFTP succeeds, but update not installed).
From a long search, the Archer C7 page has a section that talks about product_id and product_ver comparison that may be done during TFTP and may be the issue. I will next be trying to install some older versions of Openwrt and if that doesn't work, will try to figure how to modify those fields in the firmware files.

I also tried erasing the jffs2 partition and it shows in the kernel log the same Newly-erased block contained word errors mentioned in OP.

umount /rom/overlay
mtd erase /dev/mtd5

Worried it may be a kernel bug like below, in which case not sure how to fix:
https://forum.openwrt.org/t/19-07-2-mount-root-failed-cp-a-tmp-root-rom-overlay-not-a-tty/61980/3

For what it's worth, as an update I did try hex editing the factory 190403 firmware file, changing the field that shows 6D 00 00 80 and the 4 bytes right after which appears to be the product id and product ver, but neither setting all to FF or 00 helps.

I opened the other brand new A7 v5 I had, hoping to SSH or Telnet into it to get mtd backups of a stock router, but found there is no way to do so on TP-link stock. Router came with version 20200721 (a bit older than the version the first one came with).

Later on this second router, I just TFTP stock 190403 (oldest stock version available) which went fine. Then TFTP OpenWrt 19.07.7 (given I know it worked fine in previous router and I don't dare try 21.02.1 again) and that went fine also. I then set a password and tried reboot to verify everything working fine (also logs don't show the same errors about "Newly-erased block contained word"). Then as a sanity check, I TFTP stock 190403 again and it went fine also (interesting thing is it retains the password, doesn't ask me to set password). I TFTP OpenWrt 19.07.7 and it appears password is reset, but setting it and rebooting it is retained, so everything seems to be working fine.

I notice when TFTP successfully installs firmware, it takes a much longer time to turn off the WPS light (proportional to image size, OpenWRT at only 4MB was faster) and reboot, although upload takes the same amount of time (almost instantaneous). This at least verifies there is absolutely nothing wrong with the TFTP process I am using, there is simply something that went wrong with the first router by installing 21.02.1 via TP-Link UI version 201029. Still trying to figure how to proceed on first router.

As an update, I tried hex editing 201029, still can't get it to take.

I also tried the mtd commands. I copied all the mtd images from the working router. The factory-uboot and uboot are different in the working router (checked with hex editor). It could be possible they were both different from factory, but also possible the 21.02.1 update via TP-Link UI changed things.

I tried using mtd commands to write the various files to mtd2 (firmware partition). It doesn't seem to take at all. Also tried unlocking and kmod-mtd-rw to overwrite mtd0 and mtd1 using bins from the working router, and it doesn't seem to take (no errors in command line but no change to partition).

So still no progress on this.

Sounds like the next step is probably a serial recovery.

I tried serial recovery and it doesn't work either. I didn't want to do serial recovery because it was invasive, but figured a way to make secure temporary connections without soldering. Basically taping a L shaped piece of solder I made flat with pliers to bridge the R24/R27 connections to the RX pin. For the connections to the 3 pins, I use the male dupont wires included with my CP2102 angled, I taped down wires so there is pressure and it keeps the wires angled for a secure connection.

Looking at the serial output during tftp recovery, the tftp progress seems to go ok, it's just it seems for some reason it doesn't actually write to the chip.

Firmware downloaded... filesize = 0xec2313 fileaddr = 0x80060000.
Firmware Recovery file length : 15475475

Firmware process id 2.

handle_fw_cloud 138

Image verify OK!

Firmware file Verify ok!

[Error]sysmgr_proinfo_buildStruct():  659 @ unknown id(device_name), skip it.

[Error]sysmgr_proinfo_buildStruct():  659 @ unknown id(country), skip it.

[Error]sysmgr_proinfo_buildStruct():  659 @ unknown id(hw_ver), skip it.

[Error]sysmgr_cfg_checkSupportList(): 1023 @ specialId 45550000 NOT Match.

Firmware supports, check OK.

 (curFw_ver, newFw_ver) == (1.0, 1.0)

Firmware Recovery check ok!

set integer flag to 0.

######################################################################
######################################################################
######################################################################
#################################
Done.
set integer flag to 1.

Firmware Recovery Success!

All Done!
now restart...▒

I tried to manually do serial recovery using a sysupgrade image, but although the commands all complete successfully, it keeps booting back to the same image. It seems like the flash chip is working like it is read only. I tried commands like "protect off all" but it seems the serial console does not support that, so not sure what is going on.

ath> tftp 0x81000000 sysupgrade.bin
Trying eth0
dup 1 speed 1000
Using eth0 device
TFTP from server 192.168.0.10; our IP address is 192.168.0.2
Download Filename 'sysupgrade.bin'.
Download to address: 0x81000000
Loading: ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         ################################
         #####
done
Bytes transferred = 5701945 (570139 hex)
ath> erase 0x9f040000 +800000
Erasing flash...
First 0x4 last 0x83 sector size 0x10000                                                                                   131
Erased 128 sectors
ath> erase 0x9f040000 +800000
Erasing flash...
First 0x4 last 0x83 sector size 0x10000                                                                                   131
Erased 128 sectors
ath> cp.b 0x81000000 0x9f040000 0x800000
Copy to Flash... write addr: 9f040000
done
ath> bootm 0x9f040000

I also tried loading a initramfs version of 19.07.7 into RAM and doing a sysupgrade from that, but although again everything seems to go fine, nothing changes after reboot.

For a serial recovery, you should be using the squashfs-factory image.

This doesn't make much sense. Make sure you're using A7 builds not C7 as the partitioning is different.

Try TFTP booting the snapshot initramfs. Once that is running you should back up the important partitions:

cat /dev/mtd0 > /tmp/factory-uboot.bin
cat /dev/mtd1 > /tmp/u-boot.bin
cat /dev/mtd9 > /tmp/art.bin

(check partition numbers with cat /proc/mtd, it should have a table with these names and numbers.) If you have an interest in returning to factory, also get mtd2, which is the firmware. scp these files to your PC then scp up the 21.02 sysupgrade and install it with sysupgrade.

I used the sysupgrade version given this thread uses it:

Plus I have been examining the hex and binwalk of a bunch of files already and the factory ones have some extra headers in it that makes it not match the firmware header in the mtd2, while the sysupgrade one seems to match what is expected of a firmware image.

Anyways, I tried the squashfs-factory images (both 19.07.7 and 21.02.1) and there is no difference. Also doesn't matter if I erase the exact size of the files or if I erase more. It doesn't seem to matter, what seems to be happening is the flash isn't getting erased/written to.

Yes, I am using A7 builds, not C7. I have backed up all the files already a while ago, mtd0 all the way to mtd9. Did it because I tried mtd -write and it doesn't seem to work (the flash doesn't seem to be written to).

I have done the procedure of booting initramfs the 19.07.7 version, and doing a sysupgrade. Just tried the snapshot initramfs, and a sysupgrade to 19.07.7. There are no errors, but again, after reboot, everything is back to the same (still stuck on 21.02.1, no settings are saved).

Watchdog handover: fd=3
- watchdog -
Watchdog did not previously reset the system
Wed Jan 12 04:50:56 UTC 2022 upgrade: Sending TERM to remaining processes ...
Wed Jan 12 04:51:00 UTC 2022 upgrade: Sending KILL to remaining processes ...
[  461.292102] stage2 (2483): drop_caches: 3
Wed Jan 12 04:51:06 UTC 2022 upgrade: Switching to ramdisk...
Wed Jan 12 04:51:08 UTC 2022 upgrade: Performing system upgrade...
[  463.546428] do_stage2 (2483): drop_caches: 3
Unlocking firmware ...

Writing from <stdin> to firmware ...
Wed Jan 12 04:51:11 UTC 2022 upgrade: Upgrade completed
Wed Jan 12 04:51:12 UTC 2022 upgrade: Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource [  467.214193] reboot: Restarting system