amtm USB "DCL" (disk check log) constantly "Recovering Journal"?

[ColinTaylor]

Just a note to say that I've opened an issue on github about this here.

 

[thecheapseats]

Just a note to say that I've opened an issue on github about this here.

thanks Colin - a good read, and the issue(s) have been enumerated... does your prior add-line to 'services-stop' remain for the time being?... that worked for me as well... again, thanks for running this to ground...

I don't have ttl/serial for debug jacked into the ax86(s) yet - as I wasn't sure if I'd need to send the ax86(s) back - but do have the debug jacked on the ax88(s) which don't exhibit the problem, so I'm of no help...

 

[ColinTaylor]

thanks Colin - a good read, and the issue(s) have been enumerated... does your prior add-line to 'services-stop' remain for the time being?... that worked for me as well... again, thanks for running this to ground...

Yes, for the time being I'd leave that swapoff command in services-stop. Alternatively, if you have other (non-Entware) things in unmount that need to be stopped you can use /sbin/ejusb -1 1 instead of swapoff.

For the long term I think we'll have to wait and see if Merlin/Asus can fix the underlying problem with unmount.

 

[John Fitzgerald]

thanks Colin - a good read, and the issue(s) have been enumerated... does your prior add-line to 'services-stop' remain for the time being?... that worked for me as well... again, thanks for running this to ground...

I don't have ttl/serial for debug jacked into the ax86(s) yet - as I wasn't sure if I'd need to send the ax86(s) back - but do have the debug jacked on the ax88(s) which don't exhibit the problem, so I'm of no help...

For some reason mine did not stick. I do nightly reboots.

I tried different combinations of the scripts. Skynet kept giving me fits (disappearing act) so I started from scratch, wiping the USB drive. Running all 3 again fresh.

I just reapplied the patch now and the reboot came up clean, so I will wait and see.

Thanks.

 

[ColinTaylor]

Ha! Wouldn't you know it, just as I posted my previous reply I got an email saying that RMerlin has fixed the problem. It must be magic.

shared: handle both old and new sysfs format in exec_for_host() (fixe… · RMerl/asuswrt-merlin.ng@a754c6d

…s #761); fix potential crash Allows both old and new sysfs format to work, fixing it for all platforms including the RT-AX86U. Also null-terminate the readlink() result, otherwise subsequent acc...

github.com

 

[RMerlin]

Ha! Wouldn't you know it, just as I posted my previous reply I got an email saying that RMerlin has fixed the problem. It must be magic.

shared: handle both old and new sysfs format in exec_for_host() (fixe… · RMerl/asuswrt-merlin.ng@a754c6d

…s #761); fix potential crash Allows both old and new sysfs format to work, fixing it for all platforms including the RT-AX86U. Also null-terminate the readlink() result, otherwise subsequent acc...

github.com

After discussing it with Asus engineers, we opted for handling both the old and the new format, automatically falling back to the other one if the first one failed. This should be easier to maintain than adding yet another #if exception block to handle the RT-AX86U and RT-AX68U.

 

[ColinTaylor]

After discussing it with Asus engineers, we opted for handling both the old and the new format, automatically falling back to the other one if the first one failed. This should be easier to maintain than adding yet another #if exception block to handle the RT-AX86U and RT-AX68U.

Thanks for the patch and explanation, it's much appreciated.

 

[thecheapseats]

Ha! Wouldn't you know it, just as I posted my previous reply I got an email saying that RMerlin has fixed the problem. It must be magic.

Magic or good timing - either way, I'll take it... it was driving me nuts on the ax86(s) since they were new...

thanks @RMerlin and thanks @ColinTaylor ...

 

[thecheapseats]

For some reason mine did not stick. I do nightly reboots.

hmmm... that 'services-stop' edit was persistent across both warm and cold boots for me... wax-on/wax-off time - and as I was testing, I'd rebuild the install from scratch each time, just because... sounds like the next firmware roll-up will make the edit unnecessary... good...

 

[John Fitzgerald]

@ColinTaylor @thecheapseats

Update:

With regards to the patch "swapoff -a" not sticking, it appears that maybe script updates or any script change (add, deletion or update) causes it to loose its place hold.
The overnight reboot resulted in "recovering journal". No other changes were made.

When I was experimenting with different combination of scripts, any change resulted in the patch being lost (or not staying in place). I think this could be due to "blocking list updates" with the overnight failure, even if the lists are already up to date.

 

[ColinTaylor]

@John Fitzgerald I don't know why your modification is being removed. I suggest that instead of using swapoff -a you try using /sbin/ejusb -1 1 instead and seeing if that sticks. The end result should be the same provided that the unmount script contains a swapoff -a command.

P.S. Make sure your services-stop script contains #!/bin/sh as its first line.

 

[thelonelycoder]

When I was experimenting with different combination of scripts, any change resulted in the patch being lost (or not staying in place). I think this could be due to "blocking list updates" with the overnight failure, even if the lists are already up to date.

Could you apply the patch and then post the output of
cat /jffs/scripts/services-stop
Then reboot and run command again and post (altered) output.

 

[John Fitzgerald]

Could you apply the patch and then post the output of
cat /jffs/scripts/services-stop
Then reboot and run command again and post (altered) output.

Yesterday I applied swapoff -a and overnight it reverted to "recovering journal" on the reboot schedule.

This morning I applied /sbin/ejusb -1 1 and rebooted and it was clean.

I was going to wait until overnight again to check it but after your post I rebooted now and it was "dirty" again.

Below are the results. If I've done them incorrectly let me know.

Thank you.

 

[ColinTaylor]

Your "before" image doesn't show that you made any changes.

We wanted you the make the edit to the file, save it and then show us the contents before you rebooted.

 

[John Fitzgerald]

Your "before" image doesn't show that you made any changes.

We wanted you the make the edit to the file, save it and then show us the contents before you rebooted.

Would you provide an example as maybe I'm not doing this correctly.

Should it look like my image in post #13. (the info you want)

If it's my error how are you saving the change. I'm unsure and this may be my fault.

Thank you.

 

[ColinTaylor]

No, neither of your images show that you've made any changes to that file. How are you attempting to make the changes?

Your file should look like this:

#!/bin/sh
/opt/etc/init.d/rc.unslung stop # Added by Diversion
sh /jffs/scripts/firewall save # Skynet
swapoff -a

I'm using vi to edit the file. You may prefer to use nano.

 

[John Fitzgerald]

No, neither of your images show that you've made any changes to that file. How are you attempting to make the changes?

Your file should look like this:

#!/bin/sh
/opt/etc/init.d/rc.unslung stop # Added by Diversion
sh /jffs/scripts/firewall save # Skynet
swapoff -a

I'm using vi to edit the file. You may prefer to use nano.

My frustration level is high right now.

I'm stopping now.

Thank you.

 

[ColinTaylor]

My frustration level is high right now.

I'm stopping now.

Thank you.

A simpler solution might be to wait for the next official Merlin release or install the beta version that he released a few hours ago that has the necessary patch. No editing required.

 

[thecheapseats]

My frustration level is high right now.

I'm stopping now.

Thank you.

two things which I mentioned to @ColinTaylor after living with this problem for six months before speaking with him in PM some time ago - as I thought it was an amtm 'dc' related issue or a script issue (which it isn't)...

(1) think about it... until this is rolled up in the next firmware release - if the 'dirty' flag is actually true and not a false positive, then 'recovering' the journal each reboot to a 'clean' state is (and has been) working properly...

(2) and given (1) above, I was simply going to live with the recovering issue doing what it was designed to do over the last six months until someone figured it out...

also a procedural point - appending the 'swapoff -a' line to services-stop - I have done that after the install of both diversion and skynet... but now I'll watch my system too - as each multiple-script deploy in every user's system can be different... [edit} but to note - I have rebooted several times and the appended line has remained intact...

 

[Stephen Harrington]

A simpler solution might be to wait for the next official Merlin release or install the beta version that he released a few hours ago that has the necessary patch. No editing required.

Confirmed that the 'extra" swapoff entry in services-stop is no longer necessary with 386.3_beta2 for my RT-AX86U at least ...