Save & Apply not working

Installing and Using OpenWrt
1

EA8300 running 24.10.5

Although the router is doing its job well it apparently doesn’t like change. Using Luci, I tried to add an IPv6 address of my PiHole to the LAN Interface DNS setting. Save function worked but the Save & Apply does not. The system briefly shows a message that the changes have been performed but they haven’t and Luci shows the changes are still waiting.

Also tried via Luci to set the IPv6 service as disabled and that too had the same issue; no changes are being accepted. All edits remain in Unsaved Changes and status is Pending.

System Log response:

Mon Apr 13 15:35:12 2026 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Mon Apr 13 15:35:55 2026 daemon.info dnsmasq[1]: read /etc/hosts - 14 names
Mon Apr 13 15:35:55 2026 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 20 names
Mon Apr 13 15:35:55 2026 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 16 names

What’s going on?

Memory:

Available 83 / 240 MB

Used 147 / 240 MB

Cached 26.5 / 240 MB

Storage:

Disk 0.7 / 63 MB

Temp 1.75 / 121 MB

2

This is likely the issue. Your flash storage may not have enough room to save files anymore.

Is your image customized and/or did you install packages post-flash? Is there anything else you're storing in flash?

What is the output of:

ubus call system board
df -h
mount
3

ubus call system board

{
"kernel": "6.6.119",
"hostname": "Router-Downstairs",
"system": "ARMv7 Processor rev 5 (v7l)",
"model": "Linksys EA8300 (Dallas)",
"board_name": "linksys,ea8300",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.5",
"revision": "r29087-d9c5716d1d",
"target": "ipq40xx/generic",
"description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
"builddate": "1766005702"
}
}

df -h

Filesystem Size Used Available Use% Mounted on
tmpfs 120.7M 1.7M 118.9M 1% /tmp
overlayfs:/overlay 63.3M 704.0K 59.3M 1% /
tmpfs 512.0K 0 512.0K 0% /dev

mount

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
overlayfs:/overlay on / type overlay (ro,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)

For completeness, a recent (several weeks ago) Attended Sysupgrade to 25.12.2 went poorly such that the system eventually rebooted to the previous (now present) firmware. This has been stable aside from the inability to Apply changes.

I think the storage is not a limitation issue as it is reporting only 1% used rather than 1% remaining. Moreover, the issue seems to be write-ability. For S&Gs, I just attempted an Attended Sysupgrade to 24.10.6 and it too completely borked. Had to cycle power several times to get the unit to reboot 24.10.5. Hmm… what’s odd and conflicting is that the files in etc/config can be edited and saved successfully via SSH. Sooooo, what’s perplexing Luci?

Help!

4

You're right... I misread it. Thanks for the clarification.

However...

The above indicates that your overlayfs is in read only mode.

I'm not exactly sure what specifically causes this situation, but you might want to reinstall OpenWrt to see if that fixes it.

5

For clarity, the 24.10.6 attempted Attended Sysupgrade was just such an exercise and it failed. Is there a specific type of install to be performed here? We know Sysupgrade isn’t remedying the issue. Given that the 25.12.2 failed as well I’m thinking the second partition? is corrupt. But then why would that negatively affect Luci in the present partition?

Can Factory suite be installed via Luci and/or would Kernel be the more appropriate flavor?

Can the overlay simply be told to Read/Write?

Mount results have mysteriously changed. Was reading about overlays and ran mount | grep /overlay/upper and saw that it showed rw so re-ran the plain mount command alone which provided more results plus overlay is indeed showing as rw. Strange goings on here…

/dev/root on /rom type squashfs (ro,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/ubi0_1 on /overlay type ubifs (rw,noatime,assert=read-only,ubi=0,vol=1)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)

6

Mystery uh… (re)solved??

Apparently the overlay is indeed Read/Write capable once again but like the Merovingian says, the real question is, Why. Why, did the overlay change from ro to rw? The Matrix knows … and is not giving up its secrets.

7

Did the device reboot between the two separate mount commands (intentionally or unintentionally)?

8

The attempt to perform the Attended Sysupgrade to 24.10.6 was performed in-situ and when it failed I had to move the router to the local PC to try to regain access. Failing that and after multiple power cycles it rebooted from the backup (24.10.5) firmware. So, the answer to your question is Yes. Following my running the ubus call system board, df -h, and mount commands for @PSherman the failed Sysupgrade had me initiate multiple power cycles/reboots.

Hmm…but what caused the overlay to go ReadOnly in the first place?