jffs partition is read-only and cannot format-restore

[drinkingbird]

There is nothing else to do after the volume is recreated.

You should awfully sure of that, in reality nobody totally knows what the firmware does to the flash during a hard reset. If nothing else, it would be nice to verify that the firmware is now able to format it during the reset, giving some indication that things are now set up and working correctly with the file system.

 

[sfx2000]

We all knew that. How do you suggest that to happeb?
Have you figured out a way or method to “clean” the file system that is not what I have discovered and shared here ?

JFFS itself is usually pretty robust - having an open file and getting a power loss could be one reason, the other could be a task timing out during an erase/write operation (remember, with flash, you have to erase first, then write the block).

 

[ColinTaylor]

JFFS itself is usually pretty robust - having an open file and getting a power loss could be one reason, the other could be a task timing out during an erase/write operation (remember, with flash, you have to erase first, then write the block).

If you look at the output he provided you'll see that he's not using JFFS. JFFS is just the name given to device/volume/mountpoint for historical reasons. The actual filesystem type is ubifs.

 

[sfx2000]

If you look at the output he provided you'll see that he's not using JFFS. JFFS is just the name given to device/volume/mountpoint for historical reasons. The actual filesystem type is ubifs.

senior moment - thinking ubifs and typing jffs - the same thing would apply here as well - adverse events like the write timeout or loss of power with open files would still apply...

Should be rare one would hope, as we noted here in the thread, recovery can be a challenge - Joe Sixpack isn't likely to be open to digging into MTD partitions and what not, he's going to return the device to the seller, and probably not buying another one...

For others - bootloader recovery I would think could fix things, but that is extreme compared to the hard/soft resets...

 

[Clark Griswald]

Curious, has this been the only solution found for fixing a ubifs from read only to writable?
Our 6000 has become read only, and this has been the only solution I have discovered.

 

[ColinTaylor]

Curious, has this been the only solution found for fixing a ubifs from read only to writable?
Our 6000 has become read only, and this has been the only solution I have discovered.

If rebooting the router or doing a hard reset doesn't fix it then recreating the volume is the only other way I'm aware of.

 

[Viktor Jaep]

Curious, has this been the only solution found for fixing a ubifs from read only to writable?
Our 6000 has become read only, and this has been the only solution I have discovered.

Any idea how this may have happened? It was working before, right? Scary thought, that jffs all of a sudden just becomes read-only?

Are you running BACKUPMON? If so, you could do a reset, format JFFS and your EXT drive, and then restore and be back in business with no data loss?

 

[Clark Griswald]

Viktor, I'm asking you, why would I need BACKUPMON? Oh Ya, for this exact situation

Power Loss is the only cause I can conclude, since this 6000 has been working flawlessly. Router and modem (s33) were on an APC backup (out of warranty) that died suddenly.
OR
It could be a conspiracy by Asus to force me to buy the GT-BE98 Pro with RMerlin support, of course!
After two hours of following the above commands, I can't get past:
#Delete volume 13 (we can't use it anyways)
ubirmvol /dev/ubi0 --vol_id=13
There is always a process running. I can't find which process(es) are running. Searched stackoverflow, and tried numerous commands to get past my stopping point, but no success.
I will attempt more tomorrow.

 

[KevTech]

GT-AX11000 PRO with 388.2_2_rog

Wonder if this happens with 388.4 rog firmware.

 

[glens]

How many bad erase blocks are there in that portion of NVRAM? Would have to look, but believe something like

mtdinfo -M /dev/mtd13

would tell.

"Feels" rather like the journal might've suffered corruption from existing at least in part in one which failed.

 

[glens]

I can't get past:
#Delete volume 13 (we can't use it anyways)
ubirmvol /dev/ubi0 --vol_id=13
There is always a process running. I can't find which process(es) are running.

There's an "lsof" command present in the current version of Merlin on the GT-6000

 

[ColinTaylor]

After two hours of following the above commands, I can't get past:
#Delete volume 13 (we can't use it anyways)
ubirmvol /dev/ubi0 --vol_id=13
There is always a process running. I can't find which process(es) are running. Searched stackoverflow, and tried numerous commands to get past my stopping point, but no success.
I will attempt more tomorrow.

Don't just blindly type in the commands from that other post. First you need to determine whether the cause of your filesystem being read-only is the same as the OP's. If it is you then need determine what flash/filesystem layout is being used by your GT-AX6000, which might not be the same as the GT-AX11000 Pro. If the underlying problem is a corrupted metadevice you need to take additional steps before attempting the recreate the UBI volume.

 

[JGrana]

Hmm, 2 points start to make a trend.

I would hope Asus provides some additional tools with a future update. The migration from jffs2 to ubifs was their decision (or Broadcom).
I can’t imagine the return rate from “normal” users if this failure continues without a solution.

Hopefully some software magic and take care of it - unless it is a hardware failure.

 

[Viktor Jaep]

Viktor, I'm asking you, why would I need BACKUPMON? Oh Ya, for this exact situation

Well, once your read-only situation is fixed, then it would help!

Power Loss is the only cause I can conclude, since this 6000 has been working flawlessly. Router and modem (s33) were on an APC backup (out of warranty) that died suddenly.
OR
It could be a conspiracy by Asus to force me to buy the GT-BE98 Pro with RMerlin support, of course!

Supposedly UBIFS is able to bounce back from powerloss corruption events, but I guess sh*t happens.

After two hours of following the above commands, I can't get past:
#Delete volume 13 (we can't use it anyways)
ubirmvol /dev/ubi0 --vol_id=13
There is always a process running. I can't find which process(es) are running. Searched stackoverflow, and tried numerous commands to get past my stopping point, but no success.
I will attempt more tomorrow.

Not sure if this was considered, but I would also try just installing stock firmware + multiple resets with it, hoping that it may have other workarounds built-in to help get this volume working again. Once you do, then hopefully it's safe to go back to Merlin FW?