Config lost, possible dying flash, how to diagnose?

Installing and Using OpenWrt
1

I have a TCP-Link AC1750 (aka. Archer C7 v5) which has been running OpenWRT with no problems for a couple years. Today it reset itself twice and lost its configuration. SSH keys TLS keys, WiFi settings, static DHCP info, and such are gone. The root password disappeared at one point, so I did a soft factory reset and that at least seems to be holding.

I create a nightly backup using "sysupgrade -b", so I restored that using "sysupgrade -r" and rebooted. The configuration didn't stick. Tried again with the previous night's backup, same result. There are no error messages from sysupgrade, it just doesn't seem to "stick".

How can I figure out what is actually going wrong? I suspect the flash on the router may be dead or dying. At least the block(s) involved in the configuration. But I am not familiar enough with the hardware or tooling to know how to go about troubleshooting.

Thanks in advance!

Edit: OpenWRT info...
ath79/generic
OpenWrt 21.02.3 r165

2

What is the output of the following?
mount; df -h; echo test > /root/test; cat /root/test

1 Like
3

Just to clarify this, where are you saving the backup?

If you've been taking a backup every day for years and you save it to the flash, even temporarily, that'd be thousands of writes to the flash and could, indeed, cause parts of it to die. On the other hand, if the backups are saved in e.g. /tmp, then there's zero reason why the flash would suddenly die (well, unless you've set up some service that keeps writing to it) -- with the default packages and settings, OpenWrt doesn't write a single bit to the flash, none, so there's nothing to wear it out.

5 Likes
4

Seems to work fine...

root@OpenWrt:~# mount; df -h; echo test > /root/test; cat /root/test
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /tmp/root type tmpfs (rw,noatime,mode=755)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
/dev/mtdblock9 on /overlay type jffs2 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
Filesystem Size Used Available Use% Mounted on
/dev/root 3.5M 3.5M 0 100% /rom
tmpfs 60.3M 76.0K 60.2M 0% /tmp
tmpfs 60.3M 68.0K 60.2M 0% /tmp/root
tmpfs 512.0K 0 512.0K 0% /dev
/dev/mtdblock9 9.6M 3.0M 6.5M 32% /overlay
overlayfs:/overlay 9.6M 3.0M 6.5M 32% /
test
root@OpenWrt:~#

1 Like
5

The backups are saved to /tmp:

today=$(date "+%Y%m%d")
filename="backup-$today.tar.gz"
ssh -q 192.168.1.1 "sysupgrade -b /tmp/$filename" >/dev/null 2>&1
scp -q 192.168.1.1:"/tmp/$filename" "/var/backups/local/router/master/$filename"
ssh -q 192.168.1.1 "rm -f /tmp/$filename"

6

And where so you save the backups after /tmp?

(You are aware /tmp is a RAM-based drive that disappears on power down or reboot, correct?)

I just want to make sure the disaster recovery plan for your router doesn't fail with your first disaster.

1 Like
7

In their reply to me above your comment , OP does display that they're using scp to copy the backup-file from the router's /tmp to a local filesystem on another device.

4 Likes
8

I see now, my bad!

Thanks.

@tdm - if any tests work out, I'd check the cheapest thing to replace next, the power supply.

1 Like