-
-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't restore huge userdata (over 200Gb) #1241
Comments
I think the current implementation of Thinking about it, a possible solution could be to split the file into smaller chunks and write them sequentially to avoid hitting these memory limits. Does the failure occur immediately when it tries to flash userdata, or does it fail partway through the process? I haven't gone through the entire logic of mtkclient's write function, so I might be missing something (or I might be simply wrong). |
@R0rt1z2 As for writing in chunks, I would rather wait for someone to code it properly, since I simply do not have another 230 gigs of storage to accommodate the pieces. Plus, after every write the device goes into the DA mode and I have to replug or reset it in order to get back into the BROM more. But I also tried with fastboot (got the latest release from https://developer.android.com/tools/releases/platform-tools a week or so ago). And that fails as well after writing several hundred megabytes (probably also going into DA mode, not sure) |
Yeah, I was referring to handling the split within the function itself; the end user shouldn't have to touch userdata at all, as it would be a hassle to manually split such a large image. I’d be happy to submit a PR, but all my (MTK) devices have relatively small partition tables, so I don't think I'd be able to test it on my end. As for fastboot, I assume you've tried both actual fastboot and fastbootd. If I recall correctly, the fastboot protocol itself has a max download size, and from what I’ve seen, some OEMs (like Motorola) split large images (usually system) into system.sparsechunk.1, 2, etc. So, it might be a similar issue but in a different context. I don’t think the device goes into DA mode from fastboot, though; that’s completely unrelated. |
I can't restore my userdata to the way it was before my experiments, rendering the entire238 Gb of data useless.
Actually, this happens with other large files - such as super.bin (this one is 9Gb).
Small files are being written w/o any issues (e.g. boot_a of 64Mb).
It seemingly starts to write stuff but then fails.
Maybe the part that's written is actually a bypass and has nothing to do with the actual userdata.
Hard to tell with --debugmode enabled.
Stack trace
Pulled mtkclient on 10/07/2024
127c353b397bd2681f63d3b16fd5b3dfa369e8e6
.I've attached the entire log, but it's so repetitive, I don't even know whether it's helpful at all.
Logs are from a Windows 11 machine, but the same thing happens on re_livev4 (after pulling the latest mtkclient)
userdata_flash_log.txt
The text was updated successfully, but these errors were encountered: