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

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

John Fitzgerald

Senior Member
Since setting up the new AX86U with EXT4, with Journaling turned on. (new USB drive 2GB Swap) the DCL constantly shows "Recovering Journal".

Is this indicative of a faulty drive OR a hardware model change specific to the AX86U OR something different in the 386 code base?

This appears to be different behavior from other models where the DCL Status was "Clean" most of the time.
 
Last edited:

John Fitzgerald

Senior Member
Try removing the swap file and see if you get clean boots.

After one reboot the drive showed "Clean".

So, this has been happening for months. I've clean wiped the drive 2 or 3 times on the PC, the last time the long method, suspecting a faulty drive.
The drive when connected to the PC always operates as it should and shows no errors. (NTFS or exFAT)
I also have had 2 full on crashes of the scripts I believe due to Entware / Unbound and updates? (it could be something else)

You were very specific with what to try, so what do you suspect is my problem?

Thanks.
 
Last edited:

ColinTaylor

Part of the Furniture
I had a conversation with @thecheapseats recently about the same problem on his AX86U.

My suspicion is that, a) the swap file cannot be turned off (for various reasons) on shutdown, or b) the router is crashing down rather than shutting down.

Look at the syslog entries at the beginning of the boot process to see if there are "crashlog" messages indicating that it crashed.
 
Last edited:

John Fitzgerald

Senior Member
I had a conversation with @thecheapseats recently about the same problem on his AX86U.

My suspicion is that, a) the swap file cannot be turned off (for various reasons) on shutdown, or b) the router is crashing down rather than shutting down.

Look at the syslog entries at the beginning of the boot process to see if there "crashlog" messages indicating that it crashed.

The only errors I see and they may be unrelated (file), shutdown appears clean (file):

I'm on CFE 0.0.0.6. Have not been back to stock since new and shipped with 384 code so I don't know if there has been an update through ASUS via stock.

Recreated SWAP and back to same error.

Can I provide any more details?
 

Attachments

  • AX86U Errors.txt
    1.7 KB · Views: 37

ColinTaylor

Part of the Furniture
I would start by disabling all add-on's apart from the swap file and seeing if you get a clean boot. If you do I would then start turning on the scripts one at a time and checking the boot process after each one.
 

John Fitzgerald

Senior Member
I would start by disabling all add-on's apart from the swap file and seeing if you get a clean boot. If you do I would then start turning on the scripts one at a time and checking the boot process after each one.

This problem is directly related to the creation of the SWAP file.

I uninstalled backwards from how I install.
Unbound ---> Dirty Log
Skynet ------> Dirty Log

No uninstall for Diversion so I wiped JFFS.

Drive came up clean so I thought it was a Diversion / Pixelserv problem.

When Diversion was deleted by formatting JFFS, the SWAP was eliminated ( didn't know at time, thought SWAP would survive JFFS wipe: see below).

Started adding back in the reverse order for me.

Added DCL ---> OK

Tried adding Unbound it said I needed Entware first.

Added Entware ---> OK

Installed Unbound ---> OK (but got a warning that I needed a SWAP file.)

Added SWAP ---> ERROR (this was a from scratch SWAP install ((did not pull or wipe USB prior or at any time)) and I received a warning that if I was going to intall the SWAP and use Diversion I should install Diversion first and install through its interface) I ignored warning and Installed SWAP and the ERROR came back.

Added Skynet. ---> error persists.

So, currently only Unbound and Skynet are installed. The DCL Error persists.
 
Last edited:

ColinTaylor

Part of the Furniture
Remove Unbound to determine whether it is preventing the swap file from being turned off during shutdown.
 

John Fitzgerald

Senior Member
Remove Unbound to determine whether it is preventing the swap file from being turned off during shutdown.

Only Skynet is installed now, did a complete removal of Unbound.

DCL error persists.

The logs only show, (see file):
 

Attachments

  • DCL Error 2.txt
    2.5 KB · Views: 47

ColinTaylor

Part of the Furniture
Only Skynet is installed now, did a complete removal of Unbound.

DCL error persists.

The logs only show, (see file):
Just to be clear - after you uninstalled Unbound you rebooted the router so that dcl could repair the drive. Then you rebooted again and checked the dcl log to see if the error had returned?
 

John Fitzgerald

Senior Member
Just to be clear - after you uninstalled Unbound you rebooted the router so that dcl could repair the drive. Then you rebooted again and checked the dcl log to see if the error had returned?

Yes, at the end of the uninstall of Unbound you are prompted in RED that it needs a reboot to finish and after that you need to "Y" to reboot.

I just did another reboot now, below.
 

Attachments

  • DCL Log w Errors.JPG
    DCL Log w Errors.JPG
    124.7 KB · Views: 38

ColinTaylor

Part of the Furniture
I think I see the problem. Can you post the output of these commands:
Code:
free
df -h
cat /jffs/scripts/unmount
cat /jffs/scripts/services-stop
 

John Fitzgerald

Senior Member
I think I see the problem. Can you post the output of these commands:
Code:
free
df -h
cat /jffs/scripts/unmount
cat /jffs/scripts/services-stop
 

Attachments

  • AMTM Log.JPG
    AMTM Log.JPG
    61.7 KB · Views: 44

kernol

Very Senior Member
I have the same issue - and have done a factory reset - minimal config - formatted new USB ... added disk check and NOTHING else.
Reboots from both webui and command line work with clean disk check log.

Next I added the swap using amtm - 2 Gb.

Every reboot after that "Recovering journal"...

Only workaround is to use webui to eject the USB first - then reboot ... and always get clean check log.

So the issue must be buried in the AX86U firmware - which prevents the USB from being unmounted properly by the Reboot process in the webui.
I have no idea how to fix - so just stick to manual webui eject first then webui Reboot.
 

John Fitzgerald

Senior Member
OK that's not quite what I was expecting. Can you try adding this line as the last line to services-stop and then rebooting again.
Code:
swapoff -a

DCL = CLEAN
 

Attachments

  • AMTM DCL Clean.JPG
    AMTM DCL Clean.JPG
    97.1 KB · Views: 33

kernol

Very Senior Member
OK that's not quite what I was expecting. Can you try adding this line as the last line to services-stop and then rebooting again.
Code:
swapoff -a
Worked for me as well - BIG thanks - reboots back to normal :D.
 

ColinTaylor

Part of the Furniture
DCL = CLEAN
OK that's good. Leave that line in services-stop as that is where it should be.

The question is "why isn't the swapoff in unmount not having the same effect"? I had a look at my logs and it looks like unmount might not be run during a reboot, which would be a bug IMHO. I can't test that theory until tomorrow.
 
Last edited:

John Fitzgerald

Senior Member
OK that's good. Leave that line in services-stop as that is where it should be.

The question is "why isn't the swapoff in unmount not having the same effect"? I had a look at my logs and it looks like unmount might not be run during a reboot, which would be a bug. I can't test that theory until tomorrow.

BIG Thanks 2!:)

Yes I expected it to be an error in how the Swap was formatted or AX86U code. (there is now a choice between 32bit and 64bit)

Looking forward to your theory results.
 

thecheapseats

Senior Member
OK that's good. Leave that line in services-stop as that is where it should be.

The question is "why isn't the swapoff in unmount not having the same effect"? I had a look at my logs and it looks like unmount might not be run during a reboot, which would be a bug IMHO. I can't test that theory until tomorrow.

ok... so it's not just me or the three ax86 devices I've tested - all with same result - dirty/recovering.... like I said, we knew this would come up eventually... seems like progress... good...

since our conversation way back when, I did try everything to get a clean journal with either cold boot or reboot using both cli and gui - still no luck, ever...

what's weird (as I said) is the ax88(s) don't do this - ever... always clean - but you knew that...

thanks for the heads up on progress/solution...
 

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