Well manual debugging is a hell...
I lost 2 days searching about what went wrong with verification before.
All these bug huntings made the development very slow.
But I want to fix every storage related bug before releasing another "dangerous" operation; The Restore option.
I lost 2 days searching about what went wrong with verification before.
All these bug huntings made the development very slow.
But I want to fix every storage related bug before releasing another "dangerous" operation; The Restore option.
I'm open to this. Food for thought, for later versions.
Seems like that 4 hour dump/validate resulted in a corrupted rawnand.bin anyway as I can't open in Hacdiskmount.
I'm going to retry the dump, hopefully it's not 4 hours this time. I worry about my battery.
Do I understand the hekate_ipl.ini config right that including "fullsvcperm=1" will skip the validation step and speed things up?
or is SVC validation different from the validation of the dump to eMMC?
Thanks.
I'm going to retry the dump, hopefully it's not 4 hours this time. I worry about my battery.
Do I understand the hekate_ipl.ini config right that including "fullsvcperm=1" will skip the validation step and speed things up?
or is SVC validation different from the validation of the dump to eMMC?
Thanks.
That's why it's very important to fix the verification.
Nope, the SVC is for the kernel service permissions.
The configuration commits are not online yet and in v2.3 the broken verification is forced.
If you really want to be sure you can
either compile the latest source (it uses sha256 for this and it will take 44 minutes [+ more minutes to read from eMMC/SD] for the verification),
or wait for my new release.
On the other hand, your battery wont have any problems from this. If you worry about shutting off, leave it connected to your PC or wall adapter.
(Not your phone though. It will deplete its battery.)
Because somebody made a thread on gbatemp about how you can use hekate to load backups when it was really layeredfs
Yes! Thank you, I'm going to compile and give it a shot. Maybe I can will observe other bugs.
You've been very helpful. also A+ on response time.
The master branch is not ready, yet.
It was used to make pull requests to the old upstream.
It will be ready and officially the main branch when I'll have the actual release of v3.0.
(And if you check my latest commits, I readded the 16px font.)
I've dumped 3 full raw nand files and opened them using HacDiskMount to be sure they're intact.
All three full dumps have had the below warning. Could it be something going on with HacDiskMount?
{info} Trying to read partition table from <path>/rawnand.bin
{info} Loaded primary GPT, checking secondary from offset 31268535808
{warning} Secondary GPT has invalid constants, ignoring
{info} Using primary GPT as backup is bad
The above messages are displayed in the app, but I can still see the breakdown of each segment of the NAND dump (System, User, Safe, ProdInfo, BCPKG2..., etc)[/warning]
All three full dumps have had the below warning. Could it be something going on with HacDiskMount?
{info} Trying to read partition table from <path>/rawnand.bin
{info} Loaded primary GPT, checking secondary from offset 31268535808
{warning} Secondary GPT has invalid constants, ignoring
{info} Using primary GPT as backup is bad
The above messages are displayed in the app, but I can still see the breakdown of each segment of the NAND dump (System, User, Safe, ProdInfo, BCPKG2..., etc)[/warning]
Last edited by 1LastRide,
What file size these backups have?
I'll also try latest hacdisk to see what it says for my yesterday made backup.
Similar threads
