A unique issue of Safehax/D9WIP's Auto CTRNAND Transfer on JPN 2DS (20161113 OK but 20170130/0214 NG, unable to reproduce this issue currently)

[MelonGx]

The 2DS has 1.84GB NAND chip & NAND validation failure. (But since the old version can do the CTRNAND Transfer successfully, I don't think the NAND type & the NAND validation are the problem.)

On Safehax/20170130: It interrupted and outputed this immediately.

On Safehax/20170214: It could be processed to this seedsave.bin step, but froze on it.

On Safehax/20161113: The CTRNAND Transfer was successfully completed.

I don't know why the old version is OK but the recent versions doesn't. If it can be fixed on next version .....

[d0k3]

Okay, well, I'm stumbling in the dark right now. I do wonder, though, on that screenshot you made for the 20170214 version, the CMACs seem to be already fixed - that's rather strange, cause they never are in an image provided with the guide(tm). Did you perhaps make these transferables yourself? Did you ever try with any official ones?

[MelonGx]

make these transferables myself Yes.

try with any official ones You mean System Transfer or D9WIP releases but not nightlies?

[d0k3]

I mean the CTRtransfer images provided by @Plailect. I have a suspicion something goes wrong here because of your transferables. If there is no trouble with the ones Plailect provides, I'd like to take a look at your transferables (if that is okay for you, we can discuss that on temp or IRC and I'd give you instructions on what personal data to remove).

Also... if it is about the transferables, it may make sense to test the image that failed in that older D9 version.

[MelonGx]

No, they don't fail on older version, but fail at newer version. Old D9 made the transfer successful. New D9 made the transfer fail.

[MelonGx]

Oh, I'm sorry but wait a minute, what does your "transferables" actually mean? I checked I had no missed/damaged files & no wrong steps on CTRNAND transferring.

[d0k3]

By trannsferable I mean the ~1GB CTRNAND file you are using for the transfer. It is not one of @Plailect's, right?

[d0k3]

@MelonGx - I need more info to get this solved. Did you use Plailect's transferable or ones of your own. Also read what I wrote before!

[MelonGx]

@d0k3 It does be Plailect's. No problem of the image because .SHA verification is passed. But it's downloaded 7 months ago. Has it updated?

[d0k3]

@MelonGx well... maybe you could try SafeCtrTransfer? Test build here: https://transfer.sh/FkkeT/safectrtransfer-20170318-161317.zip

Instructions are found in the link. In case something goes wrong (this is tested, but unreleased), SafeCtrTransfer provides options for recovery. Something going wrong is unlikely, though.

Also, I'm still clueless about what could cause this on JAP consoles.

[d0k3]

And, also recommended, try the latest D9 hourly from here: https://d0k3.secretalgorithm.com/

[MelonGx]

Since the 2DS has been successfully CTR-transferred by 20161113 release & has returned to the owner, I am not able to test that console again .....

[d0k3]

Okay, I suggest we close this issue then, as we can't resolve it. There is still that other issue open, and the reason behing is most likely the same. What do you think?

[Jerry-Shaw]

@d0k3 , seems like version 20161113 worked. Have you got any idea about "switching header out" in the new version? Not sure about it since I cannot have my friend test with it.

[d0k3]

Well, the current hourly may work as well, but let's continue this in the other issue.

[Jerry-Shaw]

OK

[d0k3]

Closing this issue, as it was unique to that console and we have no way of reproducing it. Will be reopened if it will turn up again. Also, @MelonGx - feel free to reopen if you can add anything to it.

[MelonGx]

@d0k3 OK if I engage any other problem similar to this.