I had this exact issue in January on my first AXE11000 I bought from ebay.
I tried many things, including flashing directly using commands:
And was unable too as seen above.
There are other threads around here of the same issue such as:
https://www.snbforums.com/threads/data-kernel_nvram-setting-not-editable-on-gt-axe11000.85458/
I saw the error whenever I tried to make a NVRAM change as seen below:
It randomly showed up and left, sometimes with no action by me.
No flash attempts it would show up, continue to ignore it, and it would disappear again. Most of the time, I could fix it temporarily with multiple factory resets or multiple flashes.
To me, it looked like issues with the NAND flash on the router.
Looking at the logs I constantly saw errors related to UBIFS like you:
Feb 7 17:16:14 kernel: UBIFS warning (ubi1:0 pid 1): ubifs_ro_mode: switched to read-only mode, error -30
That lead me to some kinda NAND driver bug or bad hardware, kinda reconfirmed my theory on bad NAND flash.
Dear sir, I'm using an i.mx6ull (SDK 2.0.0) with a NAND flash. But, The following error occurs only on certain boards, and the file system is changed to read only. It will be recovered upon reboot, but the same phenomenon will be repeated soon. What's the cause? UBIFS error (ubi0:0 pid 6)...
community.nxp.com
Here is a copy of my log dump I still had:
Log Dump Rog. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
Me and Martinski discussed this at length for some time, I even tried to adapt the steps found here:
Interesting - the mtd drivers says ok, the ubi volume manager says ok. Hopefully it is just a filesystem issue - might be able to recover at that level. Just wondering - have you tried different factory resets - like the hold WPS button or press reset for a long time? I am surprised (like you!)...
www.snbforums.com
To wipe my data partition.
cd /
umount /data
ubinfo --devn=1 --vol_id=0
ubirmvol /dev/ubi1 --vol_id=0
ubimkvol /dev/ubi1 --vol_id=0 -s 6.7MiB -N data
mount -t ubifs /dev/ubi1_0 /data
Actual commands used: BE WARNED!
Admin@GT-AXE11000-DBF0:/tmp/home/root# cd /
Admin@GT-AXE11000-DBF0:/# umount /data
Admin@GT-AXE11000-DBF0:/# ubinfo --devn=1 --vol_id=0
Volume ID: 0 (on ubi1)
Type: dynamic
Alignment: 1
Size: 56 LEBs (7110656 bytes, 6.7 MiB)
State: OK
Name: data
Character device major/minor: 251:1
Admin@GT-AXE11000-DBF0:/# ubirmvol /dev/ubi1 --vol_id=0
Admin@GT-AXE11000-DBF0:/# ubimkvol /dev/ubi1 --vol_id=0 -s 6600KiB -N data
Volume ID 0, size 54 LEBs (6856704 bytes, 6.5 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "data", alignment 1
Admin@GT-AXE11000-DBF0:/# mount -t ubifs /dev/ubi1_0 /data
Admin@GT-AXE11000-DBF0:/# nvram erase
Admin@GT-AXE11000-DBF0:/# nvram commit
And then use the tfpd tool to restore instead of the ASUS rescue tool.
https://pjo2.github.io/tftpd64/
That worked for some time until the next firmware release I believe, and flashing that, it eventually came back.
The only "solve" in the end, was to get another AXE11000, it had no issues at all and still doesn't to this day.
Which is why I ran a AXE11000 as primary and another (the buggy one) as my test node.
If it broke I didn't care. Now I have a BE98 Pro as primary and the working AXE11000 as my test device/node.