[Solved] Configuration changes do not persist after reboot

suppose you could do a simple test next time before you reboot...;

mkdir /test
cp -arf /etc/config /test/
opkg list-installed > /test/installed
sync
reboot

if the files are there after the reboot... then maybe it's not the drive after all...

List of installed packages before sync and reboot commands. After I issue sync, files are still there. After reboot, they vanish...

root@FW6B:/# cat installed
cat: can't open 'installed': No such file or directory
root@FW6B:/# cd /test
root@FW6B:/test# cat installed
base-files - 1432-r16279-5cc0535800
bash - 5.1-2
bnx2-firmware - 20201118-3
busybox - 1.33.1-6
ca-bundle - 20210119-1
ca-certificates - 20210119-1
cfdisk - 2.36.1-2
cgi-io - 2021-09-08-98cef9dd-20
coreutils - 8.32-6
coreutils-split - 8.32-6
curl - 7.78.0-1
ddns-scripts - 2.8.2-11
ddns-scripts-noip - 2.8.2-11
ddns-scripts-services - 2.8.2-11
dnsmasq-full - 2.85-8
dropbear - 2020.81-2
e2fsprogs - 1.45.6-2
firewall - 2021-03-23-61db17ed-1
fstools - 2021-01-04-c53b1882-1
fwtool - 2019-11-12-8f7fe925-1
getrandom - 2020-10-25-9ef88681-2
grep - 3.6-1
ip-full - 5.11.0-3
ip6tables - 1.8.7-1
ipset - 7.6-1
iptables - 1.8.7-1
iptables-mod-conntrack-extra - 1.8.7-1
iptables-mod-ipopt - 1.8.7-1
jshn - 2021-05-16-b14c4688-2
jsonfilter - 2018-02-04-c7e938d6-1
kernel - 5.4.143-1-b70ee1516753f10c063dd361f74167d4
kmod-bnx2 - 5.4.143-1
kmod-button-hotplug - 5.4.143-3
kmod-crypto-hash - 5.4.143-1
kmod-crypto-kpp - 5.4.143-1
kmod-crypto-lib-blake2s - 5.4.143-1
kmod-crypto-lib-chacha20 - 5.4.143-1
kmod-crypto-lib-chacha20poly1305 - 5.4.143-1
kmod-crypto-lib-curve25519 - 5.4.143-1
kmod-crypto-lib-poly1305 - 5.4.143-1
kmod-e1000 - 5.4.143-1
kmod-e1000e - 5.4.143-1
kmod-forcedeth - 5.4.143-1
kmod-hwmon-core - 5.4.143-1
kmod-i2c-algo-bit - 5.4.143-1
kmod-i2c-core - 5.4.143-1
kmod-ifb - 5.4.143-1
kmod-igb - 5.4.143-1
kmod-input-core - 5.4.143-1
kmod-ip6tables - 5.4.143-1
kmod-ipt-conntrack - 5.4.143-1
kmod-ipt-conntrack-extra - 5.4.143-1
kmod-ipt-core - 5.4.143-1
kmod-ipt-ipopt - 5.4.143-1
kmod-ipt-ipset - 5.4.143-1
kmod-ipt-nat - 5.4.143-1
kmod-ipt-offload - 5.4.143-1
kmod-ipt-raw - 5.4.143-1
kmod-ixgbe - 5.4.143-1
kmod-lib-crc-ccitt - 5.4.143-1
kmod-libphy - 5.4.143-1
kmod-mdio - 5.4.143-1
kmod-mii - 5.4.143-1
kmod-nf-conntrack - 5.4.143-1
kmod-nf-conntrack-netlink - 5.4.143-1
kmod-nf-conntrack6 - 5.4.143-1
kmod-nf-flow - 5.4.143-1
kmod-nf-ipt - 5.4.143-1
kmod-nf-ipt6 - 5.4.143-1
kmod-nf-nat - 5.4.143-1
kmod-nf-reject - 5.4.143-1
kmod-nf-reject6 - 5.4.143-1
kmod-nfnetlink - 5.4.143-1
kmod-phy-realtek - 5.4.143-1
kmod-ppp - 5.4.143-1
kmod-pppoe - 5.4.143-1
kmod-pppox - 5.4.143-1
kmod-pps - 5.4.143-1
kmod-ptp - 5.4.143-1
kmod-r8169 - 5.4.143-1
kmod-sched-cake - 5.4.143-1
kmod-sched-core - 5.4.143-1
kmod-sched-mqprio - 5.4.143-1
kmod-slhc - 5.4.143-1
kmod-udptunnel4 - 5.4.143-1
kmod-udptunnel6 - 5.4.143-1
kmod-wireguard - 5.4.143-1
libblkid1 - 2.36.1-2
libblobmsg-json20210516 - 2021-05-16-b14c4688-2
libbpf0 - 5.10.10-2
libc - 1.1.24-3
libcomerr0 - 1.45.6-2
libcurl4 - 7.78.0-1
libelf1 - 0.180-1
libext2fs2 - 1.45.6-2
libf2fs6 - 1.14.0-1
libfdisk1 - 2.36.1-2
libgcc1 - 8.4.0-3
libgmp10 - 6.2.1-1
libip4tc2 - 1.8.7-1
libip6tc2 - 1.8.7-1
libipset13 - 7.6-1
libiwinfo-data - 2021-04-30-c45f0b58-2.1
libiwinfo-lua - 2021-04-30-c45f0b58-2.1
libiwinfo20210430 - 2021-04-30-c45f0b58-2.1
libjson-c5 - 0.15-2
libjson-script20210516 - 2021-05-16-b14c4688-2
liblua5.1.5 - 5.1.5-9
liblucihttp-lua - 2021-06-11-3dc89af4-1
liblucihttp0 - 2021-06-11-3dc89af4-1
libmnl0 - 1.0.4-2
libmount1 - 2.36.1-2
libncurses6 - 6.2-1
libnetfilter-conntrack3 - 1.0.8-1
libnettle8 - 3.6-1
libnfnetlink0 - 1.0.1-4
libnghttp2-14 - 1.43.0-1
libnl-tiny1 - 2020-08-05-c291088f-2
libopenssl-conf - 1.1.1l-1
libopenssl1.1 - 1.1.1l-1
libpcap1 - 1.9.1-3
libpcre - 8.44-3
libpthread - 1.1.24-3
libreadline8 - 8.1-1
librt - 1.1.24-3
libsmartcols1 - 2.36.1-2
libss2 - 1.45.6-2
libsysfs2 - 2.1.0-3
libubox20210516 - 2021-05-16-b14c4688-2
libubus-lua - 2021-06-30-4fc532c8-2
libubus20210630 - 2021-06-30-4fc532c8-2
libuci-lua - 2020-10-06-52bbc99f-5
libuci20130104 - 2020-10-06-52bbc99f-5
libuclient20201210 - 2021-05-14-6a6011df-1
libustream-openssl20201210 - 2020-12-10-68d09243-1
libuuid1 - 2.36.1-2
libwolfssl4.7.0.66253b90 - 4.7.0-stable-2
libxtables12 - 1.8.7-1
logd - 2020-10-25-9ef88681-2
lua - 5.1.5-9
luci - git-20.074.84698-ead5e81
luci-app-ddns - git-21.018.50423-4d5facb
luci-app-firewall - git-21.244.20922-3b3c2e5
luci-app-mwan3 - git-21.126.37401-0ddb72d
luci-app-opkg - git-21.079.58598-6639e31
luci-app-sqm - git-21.188.55209-f161b40
luci-app-vpn-policy-routing - 0.3.4-8
luci-app-wireguard - git-20.244.42172-21563a2
luci-base - git-21.231.26241-422c175
luci-compat - git-21.099.45066-7bb2fc4
luci-lib-base - git-20.232.39649-1f6dc29
luci-lib-ip - git-20.250.76529-62505bd
luci-lib-ipkg - git-18.318.71164-4bbe325
luci-lib-jsonc - git-19.317.29469-8da8f38
luci-lib-nixio - git-20.234.06894-c4a4e43
luci-mod-admin-full - git-19.253.48496-3f93650
luci-mod-network - git-21.266.56081-b613f3a
luci-mod-status - git-21.188.55036-eafe171
luci-mod-system - git-21.230.63964-c3580ee
luci-proto-ipv6 - git-21.148.49484-14511e5
luci-proto-ppp - git-21.163.64918-6c6559a
luci-proto-wireguard - git-21.243.21928-71fe35c
luci-theme-bootstrap - git-21.164.71418-bd36169
mkf2fs - 1.14.0-1
mtd - 26
mwan3 - 2.10.12-1
nano - 5.8-1
netifd - 2021-07-26-440eb064-1
odhcp6c - 2021-01-09-53f07e90-16
odhcpd-ipv6only - 2021-07-18-bc9d317f-3
openssh-sftp-server - 8.4p1-4
openssl-util - 1.1.1l-1
openwrt-keyring - 2021-02-20-49283916-2
opkg - 2021-06-13-1bf042dd-1
partx-utils - 2.36.1-2
ppp - 2.4.8.git-2020-10-03-3
ppp-mod-pppoe - 2.4.8.git-2020-10-03-3
procd - 2021-02-23-37eed131-1
procps-ng - 3.3.16-3
procps-ng-pkill - 3.3.16-3
r8169-firmware - 20201118-3
resolveip - 2
rng-tools - 6.10-3
rpcd - 2021-03-11-ccb75178-1
rpcd-mod-file - 2021-03-11-ccb75178-1
rpcd-mod-iwinfo - 2021-03-11-ccb75178-1
rpcd-mod-luci - 20210614
rpcd-mod-rrdns - 20170710
sqm-scripts - 1.5.1-1
sqm-scripts-extra - 2016-06-08-1
tc-mod-iptables - 5.11.0-3
tc-tiny - 5.11.0-3
tcpdump - 4.9.3-3
terminfo - 6.2-1
ubox - 2020-10-25-9ef88681-2
ubus - 2021-06-30-4fc532c8-2
ubusd - 2021-06-30-4fc532c8-2
uci - 2020-10-06-52bbc99f-5
uclient-fetch - 2021-05-14-6a6011df-1
uhttpd - 2021-03-21-15346de8-1
uhttpd-mod-ubus - 2021-03-21-15346de8-1
unzip - 6.0-8
urandom-seed - 3
urngd - 2020-01-21-c7f7b6b6-1
usign - 2020-05-23-f1f65026-1
vpn-policy-routing - 0.3.5-1
wireguard-tools - 1.0.20210223-2
zlib - 1.2.11-3
root@FW6B:/test#
1 Like

What are the default file and directory permissions of a standard OpenWrt install?

Here are the permissions in my system:

root@FW6B:~# cd /
root@FW6B:/# ls -al
drwxr-xr-x   19 root     root          4096 Sep 27 20:04 .
drwxr-xr-x   19 root     root          4096 Sep 27 20:04 ..
drwxr-xr-x    2 root     root          4096 Oct  1 18:10 bin
drwxr-xr-x    3 root     root          4096 Sep 27 18:56 boot
drwxr-xr-x    7 root     root          2680 Feb 21 09:06 dev
drwxr-xr-x   24 root     root          4096 Oct  5 15:53 etc
-rwxrwxrwx    1 root     root          1423 Aug 31 19:20 hoststoadd.txt
drwxr-xr-x   11 root     root          4096 Sep 30 16:45 lib
lrwxrwxrwx    1 root     root             3 Aug 31 19:20 lib64 -> lib
drwx------    2 root     root          4096 Dec 31  1969 lost+found
drwxr-xr-x    2 root     root          4096 Aug 31 19:20 mnt
drwxrwxr-x    3 root     root          4096 Aug 31 19:20 opt
drwxr-xr-x    2 root     root          4096 Aug 31 19:20 overlay
dr-xr-xr-x  154 root     root             0 Feb 21 09:06 proc
drwxr-xr-x    2 root     root          4096 Aug 31 19:20 rom
drwxrwxr-x    2 root     root          4096 Oct  3 09:24 root
drwxr-xr-x    2 root     root          4096 Aug 31 19:20 sbin
-rwxr-xr-x    1 root     root           383 Aug 31 19:20 stl.sh
dr-xr-xr-x   13 root     root             0 Feb 21 09:06 sys
drwxrwxrwt   16 root     root           420 Feb 21 09:06 tmp
drwxr-xr-x    7 root     root          4096 Oct  5 15:53 usr
lrwxrwxrwx    1 root     root             3 Aug 31 19:20 var -> tmp
drwxr-xr-x    4 root     root          4096 Oct  5 15:53 www
root@FW6B:/# cd config
-ash: cd: can't cd to config: No such file or directory
root@FW6B:/# cd /etc/config
root@FW6B:/etc/config# ls -al
drwxr-xr-x    2 root     root          4096 Oct 13 19:45 .
drwxr-xr-x   24 root     root          4096 Oct  5 15:53 ..
-rw-------    1 root     root          1240 Oct 13 19:45 ddns
-rw-------    1 root     root          4413 Sep 28 12:03 dhcp
-rw-------    1 root     root          4413 Sep 28 12:06 dhcp.0
-rw-------    1 root     root           134 Aug 31 19:20 dropbear
-rw-------    1 root     root          3064 Oct 13 13:07 firewall
-rw-r--r--    1 root     root           862 Sep 28 12:10 luci
-rw-------    1 root     root          2354 Oct  8 18:11 mwan3
-rw-------    1 root     root          1624 Oct  8 22:07 network
-rw-------    1 root     root          1640 Sep 28 12:16 network.0
-rw-------    1 root     root           167 Aug 31 19:20 rpcd
-rw-r--r--    1 root     root          1501 Oct  1 10:25 sqm
-rw-r--r--    1 root     root          1501 Oct  1 11:38 sqm.ok
-rw-r--r--    1 root     root          1624 Sep 28 19:56 sqm.seemstowork
-rw-------    1 root     root           505 Oct  2 13:10 system
-rw-r--r--    1 root     root           884 Sep 27 20:04 ucitrack
-rw-------    1 root     root           783 Sep 28 12:10 uhttpd
-rw-------    1 root     root          1186 Oct 13 13:07 vpn-policy-routing
root@FW6B:/etc/config#

these things have a 'write cache chip' much like the optane stuff I mentioned before...

looks like it's having trouble moving that 'cached' saved info back to the non-volatile chips...

probably some info on the net about it... run hwinfo to get your model and web-search 'cache write problem MODEL'

(may even be some sort of firmware update or manufacturer diagnostic tool for it)

1 Like

hwinfo...

Darn thing outputs a LOT of info... Will take a while to digest it. :rofl:

1 Like

A little update here.

Since 21.02.2 was about to land and the reason for the issue described in the OP was still unknown, I decided I would try and regenerate my custom image with the newer version, as soon as it would be made available.

Good news is the newly installed image does not suffer from the same issue. This was somehow expected, as my previous setup also did not show the issue initially.
Bad news is that I still don't know what happened with my setup to cause the OP described issue in the first place...
Let's hope the same problem does not eventually creep into the newly installed system. Fingers crossed. :crossed_fingers:t2:

1 Like

UPDATE: Since I installed the newer version on a different mSATA SSD, I decided I would format the original mSATA SSD where version 21.2.0 was installed and that was suffering from the above mentioned issue.
Lo and behold, I found out that no matter what I tried I could not do anything on the original disk. I tried fdisk, gdisk, gparted on Linux, Disk Utility on macOS and Disk Manager, as well as DISKPART (command line) on Windows.
None of the above utilities was able to change the contents of the disk. With all of them it would appear that the commands worked, but somehow things would always revert back to the original partition scheme of one 16MB ext4 partition and one [remaining disk space] ext4 partition on an MBR partition table. (Black Magic?) :thinking:
So I suppose the original disk is somewhat defective or has some kind of magic capability I never heard of before... Go figure.

3 Likes

Does anyone here know if it's possible to unlock a partition table from OpenWrt?
After some investigation, it seems the original SSD partition table got somehow locked after the power cut, but I have no clue what caused this, or how to unlock it. I have already tried everything in the post above and also tried installing Ubuntu onto this SSD. Ubuntu installation fails when the installation program tries to partition the disk... If no one comes out with a clue, I guess this SSD will go to the trash bin, which is a shame as all diagnostics I ran on it seem to indicate it's OK.

I've had that happen with USB sticks. There's a HP usb tool you can use as a last resort to try flip them off read only mode but generally if that fails? off to the great bit bucket in the sky. Not sure if you could fix an SSD with that. Whats the info you get from an SMART diagnostics program? might show up if the drive is failing?

Only other thing i could suggest is try a destructive format program like DBAN to clear it?

(edit) Just remembered, one of my old intel 40gb SSDs did that. Went read only on me. i think i ended up throwing it and getting a new one.

1 Like

Thanks for your help. I will try to find the HP tool and the DBAN tool you mentioned above and will report back with the results. Smart diagnostics say everything is working as expected on the affected SSD, that being the main reason I'm still trying to salvage it. I guess the power cut occurred at the exact moment when something was being written to the disk and that flipped some obscure bit normal tools don't look for and therefore cannot unflip.

UPDATE: Unfortunately DBAN does not work on SSD drives and the HP USB format tool does not see the SSD even though I connected it to the Windows computer via an USB to SATA adapter. I guess it only works with real USB drives.

1 Like

And it's gone into the trash bin. Got a new one which shall be here later today.

1 Like

better idea. drill hole in it and make it a keychain :slight_smile:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.