What's new

formatted Jffs repopulated on second reboot

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

martinr

Part of the Furniture
RT- AC68U. 384.6

NO USB DEVICE of any description fitted.

In the Admin > System section, I disable scripts, and enable jffs format on next boot. Hit Apply, then reboot, after which a new WinSCP session then shows the jffs folder is empty.

I reboot again, and then open fresh WinSCP session which shows the jffs folder has been repopulated: 7 file-containing folders (ssl, dnscrypt, openvpn....) and 6 files.

I’ve carefully repeated this several times now. Reboot with the power switch or through the GUI is no different: on second reboot the jffs files and folders have returned.

What’s going wrong, please?
 
Last edited:
RT- AC68U. 384.6

NO USB DEVICE of any description fitted.

In the Admin > System section, I disable scripts, and enable jffs format on next boot. Hit Apply, then reboot, after which a new WinSCP session then shows the jffs folder is empty.

I reboot again, and then open fresh WinSCP session which shows the jffs folder has been repopulated: 7 file-containing folders (ssl, dnscrypt, openvpn....) and 6 files.

I’ve carefully repeated this several times now. Reboot with the power switch or through the GUI is no different: on second reboot the jffs files and folders have returned.

What’s going wrong, please?
Leave script support enabled and format again then reboot and login with Winscp.
 
Leave script support enabled and format again then reboot and login with Winscp.

Thanks, skeal. When I first realised what was happening I had left script support enabled. Then, thinking perhaps in some obscre way that setting might be interfering, I disabled it.

But to teassure myself - and you - I’ve just tried it again, with scripting support enabled, and it’s had no effect: second reboot brings it back.

Gives a whole new meaning to “the second coming”.
 
After the first format, when you connect and /jffs is apparently empty, try copying a reasonably large file (a few MB) into /jffs. Then do your second reboot and see if that makes a difference.

P.S. I'm assuming you're rebooting by using the WebUI option and not just turning the power off?
 
The other thing you could try, is when accessing by Winscp, delete the jffs folder disable support for jffs and reboot. After reboot enable jffs support and format option. Reboot. login to winscp and check for content. Thing only thing I'm unsure of is if when the jffs is formatted in the last reboot will it create the jffs folder if it has been removed beforehand.:eek:
 
What’s going wrong, please?
Nothing....the 'quirk' of having to reboot twice to populate the jffs folders has been there for as long as I can remember.

The folders themselves are always created regardless of the script setting, since some of them are now integral to the firmware operation.
 
The other thing you could try, is when accessing by Winscp, delete the jffs folder disable support for jffs and reboot. After reboot enable jffs support and format option. Reboot. login to winscp and check for content. Thing only thing I'm unsure of is if when the jffs is formatted in the last reboot will it create the jffs folder if it has been removed beforehand.:eek:
I doubt you would be able to delete the /jffs folder because it's the root of a mounted filesystem, not a directory. However you've given me an idea about what might be going on :D.

I think the /jffs directory is showing as empty the first time because it's just the mount point and the actual filesystem has not been mounted. You can't format a mounted filesystem which is probably why you need to reboot the router twice. So, after the first boot there should be some process that runs to format the unmounted jffs partition. After the second boot the jffs partition should be mounted as usual.

My guess is that for some reason jffs isn't being formatted after the first boot. So that means that after the second boot the jffs partition reappears exactly as it was before.

Anyway that's my theory. :p
 
Nothing....the 'quirk' of having to reboot twice to populate the jffs folders has been there for as long as I can remember.

The folders themselves are always created regardless of the script setting, since some of them are now integral to the firmware operation.

But why would, for example the /jffs/dnscrypt directory, which was the main reason why @martinr formatted /jffs in the first place, re-appear? I can follow what you're saying, but why would a second boot re-create non-default directories after formatting?
 
After the first format, when you connect and /jffs is apparently empty, try copying a reasonably large file (a few MB) into /jffs. Then do your second reboot and see if that makes a difference.

P.S. I'm assuming you're rebooting by using the WebUI option and not just turning the power off?
I’ve tried rebooting both watys, Colin, but should I infer that turning the power off and then back on is inferior to using Reboot in the GUI? Do they call them a hard and soft reboot, respectively?

(I’ll try that copying idea.)
 
Nothing....the 'quirk' of having to reboot twice to populate the jffs folders has been there for as long as I can remember.

The folders themselves are always created regardless of the script setting, since some of them are now integral to the firmware operation.
Thanks, John. My original aim was to remove dnscrypt completely - I was unable to do it through AMTM. So I was especially surprised to see it return after the second reboot. Same with the OpenVPN keys and certs: I thought the format erased them completely - as it appeared after the first reboot - and yet after the second reboot they were back. Empty folders would not have surprised me but these have files in. And so the OpenVPN keys and certs disappear from the GUI after the format and first reboot only to reappear in the GUI after the second reboot. So it’s all normal!
 
I doubt you would be able to delete the /jffs folder because it's the root of a mounted filesystem, not a directory. However you've given me an idea about what might be going on :D.

I think the /jffs directory is showing as empty the first time because it's just the mount point and the actual filesystem has not been mounted. You can't format a mounted filesystem which is probably why you need to reboot the router twice. So, after the first boot there should be some process that runs to format the unmounted jffs partition. After the second boot the jffs partition should be mounted as usual.

My guess is that for some reason jffs isn't being formatted after the first boot. So that means that after the second boot the jffs partition reappears exactly as it was before.

Anyway that's my theory. :p

Tomorrow I was planning to see what happens when I format, reboot, format again and then reboot again. Your theory has given added impetus to that.
 
I’ve tried rebooting both ways, Colin, but should I infer that turning the power off and then back on is inferior to using Reboot in the GUI? Do they call them a hard and soft reboot, respectively?
It's always preferable to use the reboot option in the webUI rather than just turning the power off and on again. It's the same reason you shutdown your PC rather than pulling the power. The reboot option will cleanly shutdown processes, synchronise filesystems and commit any cached write activity. To be fair it's not normally an issue with the router because most of the processes don't write anything the permanent storage, but if you have a USB drive attached it becomes more of a concern.

Yes, hard and soft reboot.
 
It's always preferable to use the reboot option in the webUI rather than just turning the power off and on again. It's the same reason you shutdown your PC rather than pulling the power. The reboot option will cleanly shutdown processes, synchronise filesystems and commit any cached write activity. To be fair it's not normally an issue with the router because most of the processes don't write anything the permanent storage, but if you have a USB drive attached it becomes more of a concern.

Yes, hard and soft reboot.

Many thanks, Colin. I’d mistakenly thought the so-called hard reboot was the better of the 2 methods - better in the sense of guaranteed to ensure nothing survived the reboot. I’ll make sure I only use the GUI to reboot in future (ot the reboot command line option, which I guess is what the GUI’s doing).
 
Sometimes you have no choice but to turn the power off and on. Maybe after a firmware upgrade or if the router is misbehaving. But for normal day to day activity the menu option is better.

Try writing that file I suggested after the first boot. If you can't because the directory is read-only that would support the first part of my theory. Then, before rebooting again, look in the syslog for any messages related to jffs or formatting. Maybe you just have to wait a few minutes more.
 
I doubt you would be able to delete the /jffs folder because it's the root of a mounted filesystem, not a directory. However you've given me an idea about what might be going on :D.

I think the /jffs directory is showing as empty the first time because it's just the mount point and the actual filesystem has not been mounted. You can't format a mounted filesystem which is probably why you need to reboot the router twice. So, after the first boot there should be some process that runs to format the unmounted jffs partition. After the second boot the jffs partition should be mounted as usual.

My guess is that for some reason jffs isn't being formatted after the first boot. So that means that after the second boot the jffs partition reappears exactly as it was before.

Anyway that's my theory. :p
Sometimes you have no choice but to turn the power off and on. Maybe after a firmware upgrade or if the router is misbehaving. But for normal day to day activity the menu option is better.

Try writing that file I suggested after the first boot. If you can't because the directory is read-only that would support the first part of my theory. Then, before rebooting again, look in the syslog for any messages related to jffs or formatting. Maybe you just have to wait a few minutes more.


RT-AC68U 384.6. USB ports empty.


Colin, I did as you said in the final para: I set it to format jffs and then rebooted via the GUI. WinSCP then showed me an (apparantly) empty jffs. When I attempt to move a file into it, I get the error message Read-only file system. But when I then reboot - and jffs then shows all its previous files and folders - I can then move a file into the jffs directory without problem.

The only mention of jffs or format in the syslog is:

jffs2: valid logs (1)


Also, I tried formatting twice: set to format at next boot, reboot thro’ GUI, then again set to format at next boot, reboot through GUI, then reboot again, but all the files and folders are still there.

Perhaps, in desperation, I’ll try a factory reset and then try formatting jffs and rebooting twice. If by some fluke that works, I’ll restore the (non-jffs) settings from the backup and see what happens.
 
Last edited:
Perhaps, in desperation, I’ll try a factory reset and then try formatting jffs and rebooting twice.

In that case you could consider performing an 'Initialize' as well, if the other way doesn't work. Not sure whether it makes a difference, but if you're about to wipe it anyway, maybe worth a try.

While reading about your issues, I'm wondering whether I had similar issues when I did a clean install 384.7 alpha 1 last week. After a factory reset and reboot I tried to install several things through amtm and I recall having issues with /jffs being not writable at first too... I had to reboot again before I could install anything and I can't recall whether that has ever been the case before. I haven't checked whether anything was restored to /jffs after the second reboot, which belonged to the previous install.
 
In that case you could consider performing an 'Initialize' as well, if the other way doesn't work. Not sure whether it makes a difference, but if you're about to wipe it anyway, maybe worth a try.

While reading about your issues, I'm wondering whether I had similar issues when I did a clean install 384.7 alpha 1 last week. After a factory reset and reboot I tried to install several things through amtm and I recall having issues with /jffs being not writable at first too... I had to reboot again before I could install anything and I can't recall whether that has ever been the case before. I haven't checked whether anything was restored to /jffs after the second reboot, which belonged to the previous install.

Thanks, M@rco; interesting that you, too, possibly have seen this.

I was going to ask you what “Initialize” is and then realised I could use Google instead!

Here’s what Our Dear Leader says:

“This option [Initialze] is new with 382_18219. Initialize will also remove the existing content of the /jffs/.sys/ folder which contains various data such as the (forecoming) Notification Center, Web History, etc... Restore will only erase the nvram configuration.”

https://www.snbforums.com/threads/rt-ac86u-administration-restore-vs-initialize.41944/#post-355999


So it might not remove all the jffs contents, but I will indeed use it instead of the Factory Restore.

Many thanks for making me aware of it. I will try it tonight.
 
Last edited:
So it might not remove all the jffs contents, but I will indeed use it instead of the Factory Restore.

Many thanks for making me aware of it. I will try it tonight.

I actually thought it would wipe /jffs completely :oops: Thanks for doing my homework. I'll try better next time. Nevertheless, I'll hope it'll solve your issue.
 
Getting further and further away from my original aim - to remove dnscrypt - I “solved” my problem of being unable to wipe jffs clean. I simply went into jffs with WinSCP and deleted anything related to dnscrypt as well as all the script files. A bit inellegant (certainly by Windows standards) but it worked and it saved deletion of the other directories and files. Then reinstalled amtm and everything else except dnscrypt.

This solved my problem of loss of dns resolution, and all seems to be working perfectly once again.

I’m no wiser as to why I couldn’t wipe jffs, but it all ended well with quite a lot learned along the way, thanks to the kind help and advice from forum members.

...... deleting the offending files and directory individually from jffs.... why didn’t I think of that in the first place? Probably 20 years of Windows, I guess.
 
Hi Folks

I have a new Asus RT-AC68U and i installed Merlin 384.7_2
For installing my VPN applet the 'Format JFFS partition ' option reverts to 'No' after reboot.
Is this a bug in the Merlin firmware for this release ?
Secondly to downgrade to lower Merlin firmware can we apply the lower version to current firmware or we need to flash the Asus Stock firmware first and then apply the older firmware

regards
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top