Help "Error: Failed to mount /data (invalid argument)" but phone is working fine

[tyrone910]

Hey guys, I just want to share this experience. My phone is Samsung Galaxy J7 (2016). It runs Android 6.0.1 Marshmallow. Yesterday I decided to conduct a "Wipe cache partition" on my phone after installing and uninstalling lots of apps from Play Store to at least get rid of any temporary files they might have left.

I went into recovery mode and selected "Wipe cache partition" and then after it said success, I selected "Reboot system now". Then it showed "Verifying DMVerity Hash Tree..." (I don't know what that means) for at least 5 seconds and then an error text appeared. At first I was unable to take note of it because my phone rebooted immediately but I knew it was an error since the text was colored RED.

So I decided to do a wipe again and did the same procedure. This time I carefully paid attention to the error text. It only showed for maybe 1 or 2 seconds before my phone rebooted. It read "Error: Failed to mount /data (invalid argument)" or something like that. I observed my phone. Used it like I normally would and I could find no problem with it. And that is the problem now. Why would it say error when my device is fully functioning? It's very disturbing. Like some problem is lurking in the darkness waiting for it to unveil itself.

I searched the internet for problems related with "Error: Failed to mount /data (invalid argument)" and most, if not all of them, has something to do with phones stuck at boot logo.

Can you please help me? Get this worry of mine out of my mind. I have this OCD thing when it comes to personal items. Sorry for the long thread. Thank you very much and have a Happy New Year everyone.

 

[Hadron]

The reason the phone is working is that it was the recovery module that had problems, and clearly the Android OS didn't have the same problem (as /data is where your apps live).

Why recovery had 2 entirely different problems on 2 attempts I've no idea.

 

[tyrone910]

The reason the phone is working is that it was the recovery module that had problems, and clearly the Android OS didn't have the same problem (as /data is where your apps live).

Why recovery had 2 entirely different problems on 2 attempts I've no idea.

Hi, thank you for the reply. But I don't understand. Should I be worried or is it normal for Android Recovery to behave like that?

 

[Hadron]

It shouldn't do it, but re-reading your original message it seems that this error isn't in recovery but after you reboot. If so then it's not that recovery couldn't mount /data (which I have met, and would be abnormal) but that the phone didn't mount /data during some pre-boot check (though I can't imagine why it would need to mount /data for a dm-verity check, which is a check of the integrity of the system partition). But if the phone is running normally now it clearly could mount /data during the boot, so there isn't actually a problem. Possibly just some timing thing, with the message being issued prematurely?

 

[scary alien]

I've seen many (many) references to that "Failed to mount '<partition>' (invalid argument)" over the years and it's always puzzled me, too.

I'm thinking / guessing that this has to do with how the recovery knows (or in this case, doesn't know) what to do (or how to do) the remounting of a filesystem because the /cache/recovery/command file, which is used to communicate with recovery (and later the bootloader via the boot control block, which recovery updates).

Since the /cache partition is getting wiped, the /cache/recovery/command file also gets wiped, subsequently leaving recovery without information about what he might do (not saying this is an error, but just a consequence of having done the wipe of the cache partition).

It may also be that this is just a normal warning message (caused because the /data partition is encrypted and the decryption part of the boot process has not yet been reached?) you would not normally see, but since you entered into recovery, you're being presented with it.

All speculation, of course--debugging this would be onerous and would take inserting code in the stock recovery and testing following the path of what is done when the cache partition is wiped...

Bottom line: @tyrone910, if your device is otherwise booting-up and functioning fine, I wouldn't worry about it .