Open Nazosan opened 7 years ago
Hamcha
commented
7 years ago Thanks for the extensive description, including research, log et al! I've already had some reports like that and was planning to debug it these days, your issue will surely help me narrow down the problem!
I'll see if I can test and recreate the issue on either of my 3DSs at home.
Nazosan
commented
7 years ago Glad it helps. Let me know if I can provide any other details that might help, but I suppose this is just about it.
EDIT: You probably already know this, but just for the record it looks like it doesn't like the manually specified file or something about the path/filename. I just setup a N3DS system the same way and it still has the same problem.
Nazosan
commented
7 years ago Ok, I tried simplifying a bit. I put everything in a folder called "a9lh" on the root. Also, I leave the Luma3ds file named as its default "arm9loaderhax.bin" instead of renaming to Luma3DS.bin as I had previously been doing. I also set Luma3DS in its own settings to use a custom path and pointed it to that file via the /luma/path.txt file as per the instructions on the site. I noticed some things have mentioned character limits, so I thought I'd try to make sure I wasn't running into that.
Unfortunately, it seems this still can't update it. I tried overwriting the 6.5 file with the latest 6.6 and it still stayed as 6.5 even after this simplification. On the up side, it makes updating manually easier since I no longer have to rename or anything, just drag and drop straight to that folder.
GabyPCgeeK
commented
7 years ago I too was having trouble updating luma with "payload path = /anim/arm9payload.bin". The arm9payload.bin.bak was created ok but arm9payload.bin would stay the same. I downloaded the lumaupdate code and found in update.cpp the line that "opens/creates" the output file
std::ofstream a9lhfile("/" + args.payloadPath, std::ofstream::binary);
and the line that "opens/creates" the back up
std::ofstream target(backupName, std::ofstream::binary);
in the first one I noticed that it was adding an aditional / to the path that already began with / thanks to a check done in main.cpp. I changed the line to:
std::ofstream a9lhfile(args.payloadPath, std::ofstream::binary);
and now lumaupdate updates /anim/arm9payload.bin successfully.
I also added a way in config to bypass the payload patches because bootanim9 does that and also added the writing of the payload to /luma/arm9loaderhax.bin so I only need to copy/paste the file to CTRNAND.
Nazosan
commented
7 years ago This would certainly explain it. Sounds like a really simple fix too.
Now that Luma3DS can do a proper multi-boot menu I'm moving away from CTRBootMenu probably, so for now I've eliminated the custom path and can't test this stuff anymore, but it will probably never implement bootanim (or so I assume...) and I'm sure there are other things that benefit from a custom path so this should still be very useful for anyone using it at the very least.
I'm using Luma3DS along with a A9LH version of CTRBootManager. While I don't know if it's a "standard" per se, I've been seeing a lot of guides and software using /homebrew/3ds/filename.bin for payloads for whatever reason. I've chosen for now to just adopt it as something of a "standard" even though they'll probably just change it again later on. Presumably the exact location does not matter, but I wanted to include this for the record just in case it may have some sort of issue with the specific path or something.
Naturally I had to create a configuration file for lumaupdate. The file looks simply like this:
The first is probably not even necessary, I just threw it in for good measure. The log I enabled just for stuff like this. Note that I also tried with all lowercase text on the "Luma3DS.bin" and just changed it to that in case it was case sensitive for whatever reason since the filename is marked as such (though I doubt it even could be case sensitive on a FAT32 filesystem.)
So what happens when I load it with a previous version of Luma3DS running is it detects everything ok. It can see the current version I'm using, correctly shows the correct location, and all. It informs me if I need a newer version or not as it should do. When I tell it to install the normal version (I haven't messed with the dev version option) it correctly downloads the latest, makes a backup of the current payload, and then informs me that it has replaced the payload file and should reboot. Upon rebooting, the payload file has not actually been replaced. Not only am I still in the version of Luma3DS that it was supposed to have updated from, but I can verify by comparing the actual payload file itself that it is not the updated file but is, in fact the old one. I can do this as many times as I like with the same result every time: everything reports success but it is not actually updated.
As you can see I enabled the log. There are no errors reported at all in the log. Extracted ok with no errors, found the file ok with no errors, noticed my configuration saying not to replace arm9loaderhax.bin in the root and switches to the correct location and filename, reports success in replacing said file, then says it's completed without errors. Here is the log just in case it says anything of any use at all, but as far as I can determine it must be just simply not replacing the file somewhere along the way and that's all there is to it: