Closed admiralspeedy closed 1 year ago
rlaphoenix
commented
1 year ago Considering this issue is 99.9% of the time caused by bad or outdated or incomplete sigpatches, and that 16.0.2 just came out, it's more likely to be a sigpatches issue than anything.
Also, which version did you test this on? The PyPI/latest release, or the latest commit on the repo? Ideally if you could test both that would be great. I don't have a switch ready to test anything on at the moment.
admiralspeedy
commented
1 year ago Latest commit. I can't even use the PyPI release as we discussed since it doesn't find my prod.keys files (I guess I can probably go compare and see what change fixed that and apply it myself).
Sig patches have not changed between 16.0.0, 16.0.1, and 16.0.2. Only 16.0.0 introduced a new key, 16.0.1 only changed the bad word list, and 16.0.2 added one word to the JP bad word list and made a small change to the SSL module,
Either way I made new sigpatches last night myself from my own 16.0.2 dump and the the AMS 1.5.2 package3 binary (as I noted in the issue) and also the auto built HB Menu forwarder from the latest build works for me, so clearly my sigpatches are fine. I even tried reverting to the previous ExeFS ROM to confirm that it was not the cause and it still crashes as described.
Are you able to run a build for me and I will test it tonight?
rlaphoenix
commented
1 year ago Latest commit. I can't even use the PyPI release as we discussed since it doesn't find my prod.keys files (I guess I can probably go compare and see what change fixed that and apply it myself).
You could just place prod.keys wherever your terminal/cmd currently is, e.g., if your terminal has cd to Desktop, put it in the Desktop.
Sig patches have not changed between 16.0.0, 16.0.1, and 16.0.2.
That is quite strange then. This leads me to believe there could be some issue with either the new ExeFS ROM and/or the underlying nx-hbloader code.
the auto built HB Menu forwarder from the latest build works for me
Are you referring to the one under NTON releases in the Assets section? This makes it even more clear that it could be the new ExeFS ROM as that forwarder would have been built on the older ExeFS ROM.
I even tried reverting to the previous ExeFS ROM to confirm that it was not the cause and it still crashes as described
Yet by your own words, it's as if it's not the cause. Perhaps some change between the last release and now caused a problem? You can see in the GitHub commit history what changes were made here: https://github.com/rlaphoenix/nton/compare/v1.2.0...master
Perhaps you could try slowly going down the changes until it works again? You can use git checkout HEAD^1 to repeatedly remove the latest commit, and test builds until it works again. (with git checkout master to get back to the latest commit).
rlaphoenix
commented
1 year ago Also, you said in another issue:
no matter what I do, the resulting NSP does not launch for me, but your prebuilt ones do so I'm not sure what I could be doing wrong.
This sounds to me like you could be providing the NRO path from your C:/ drive. It's incredibly important to provide it from your Switch's microSD card. It's also important to never move that NRO file. Your Step 8 builds at "X:/hbmenu.nro", are you sure that file is still there?
The following is the exact build call used when making a release:
It only uses --sdmc because the path to the NRO is in this case on the C:/ drive (just by relative path). Therefore, by specifying --sdmc I can bypass the restriction of it being on the Switch's SD card since obviously, the auto-release system wouldn't have one.
admiralspeedy
commented
1 year ago You could just place prod.keys wherever your terminal/cmd currently is, e.g., if your terminal has cd to Desktop, put it in the Desktop.
I totally forgot that was an option. Will try tonight.
Are you referring to the one under NTON releases in the Assets section? This makes it even more clear that it could be the new ExeFS ROM as that forwarder would have been built on the older ExeFS ROM.
Yes. But if I build my own forwarder with the old ExeFS ROM, I still get the same issue so I don't think it's that.
poetry run nton build "hbmenu.nro" --name "Homebrew Menu" --sdmc "/hbmenu.nro"
I will try this, but as per the readme I built it as follows (my Switch SD card was plugged into my PC with a MicroSD card adapter, with the drive letter H):
poetry run nton build --name "Homebrew Menu" "H:/hbmenu.nro"
And it clearly finds the NRO properly, since it pulls the version and developer strings properly and automatically adds the correct icon and sets the title ID. The NRO is still in that location, otherwise I would never be able to launch the Homebrew Menu. I'm wondering if building it that way is adding the drive letter to the path and the Switch is look for "H:/" instead of "sdmc:/"?
rlaphoenix
commented
1 year ago I'm wondering if building it that way is adding the drive letter to the path and the Switch is look for "H:/" instead of "sdmc:/"?
If you go to this line, https://github.com/rlaphoenix/nton/blob/d68d55fb82cf789207fe7d99d5f7e51d850a7c6d/nton/main.py#L103
And after it add print(path, sdmc), what is printed? There's a possibility it will be H:\hbmenu.nro.
admiralspeedy
commented
1 year ago Yup, it outputs this:
E:\hbmenu.nro E:\hbmenu.nro
So there is something wrong with that logic. It switches the forward slash to a backslash, so is this an issue with the path resolution and the fact that Windows uses backslashes maybe?
Also, looking at the entire block that checks for the C drive, I think this logic is not the right way to go about creating the path if I'm honest. I feel like the user should just be required to specify the full sdmc path to build because I have 4 SSDs in my PC so checking only for C is kind of pointless, since I could be running this from any other drive.
I'm not at home right now so I can't connect my Switch SD card to my PC so I just remoted in to my PC and put the NRO on the root of one of my other drives (E:) and nton has no idea that E:\ is not my SD card.
rlaphoenix
commented
1 year ago Yup, it outputs this:
E:\hbmenu.nro E:\hbmenu.nro
I fixed that here, https://github.com/rlaphoenix/nton/commit/f7845a2978ae2d3f86a74beaca95baa87e5284c8 maybe it works now? I wonder if this fixes the rest of the issues you were having.
I feel like the user should just be required to specify the full sdmc path to build checking only for C is kind of pointless, since I could be running this from any other drive
While this is true, that it's not efficient, it's the only option I have. The only other possibility would be to somehow check if a Drive is a removable device, but also specifically a SD card/reader. Forcing everyone to provide the --sdmc by default is also not better since they then have to still write down the exact path and be sure of it. It just introduces more possibilities of error (e.g., typos, them misremembering the path, and if they go to check they would have the microSD open ready to use like we do now anyway).
The current way of basing it off the NRO path, then optionally having an override with --sdmc is the cleanest solution. It would be more-or-less perfect if I had a way to know for-sure if the input NRO was on an SD card or not. One way I was thinking was to get the drive path, do "X:/Nintendo" and see if this folder exists. However, this would mean that people using NTON on a completely fresh SD card would fail.
admiralspeedy
commented
1 year ago Nope, that outputs the following:
E:\hbmenu.nro E:/hbmenu.nro
So now it doesn't flip the slash on the sdmc path, but it does on the NRO path, but both still show the drive letter instead of the second one showing sdmc:/
Also, I don't quite understand the complexity issue about the paths. This tool is already more complex than what 99% of Switch users are even willing to look at, being that most of them are kids who just follow a guide to do everything. I'm a programmer myself (it's what I do for a living) and I think most people using this tool would be technically capable enough to enter in a relative path ("/" for sdmc root, "/switch/homebrew/homebrew.nro", etc). It doesn't really seem that complex to me.
I get the intent behind it, but like I said, anyone with more than one drive could easily bypass that C drive check without even realizing it. I technically would have if I hadn't read the readme because my downloads folder is on a second drive and I cloned the repo into my downloads folder.
admiralspeedy
commented
1 year ago path.resolve().absolute().as_posix().replace(path.drive, "sdmc:")
The above should work (at least it outputs correctly, I can't test the NSP until I get home).
The reason it didn't work is because "path.drive" already includes the colon, so "{path.drive}:/" ended up with two colons and didn't match the replace.
rlaphoenix
commented
1 year ago Nope, that outputs the following:
E:\hbmenu.nro E:/hbmenu.nro
Ahh, I have this properly fixed now by using anchor instead of malforming drive.
I think most people using this tool would be technically capable enough to enter in a relative path ("/" for sdmc root, "/switch/homebrew/homebrew.nro", etc)
Not sure I understand what you mean. They would need to specify the NRO path and then the SDMC path. That would be hella repetitive in various ways, prone to typos, mistakes, etc. If you're a programmer I'm sure you have encountered numerous brain-dead users across your journey lmfao. I'd rather try to make the user experience as easy as possible over dealing with 90 emails through my git commit email asking why it crashes on launch.
anyone with more than one drive could easily bypass that C drive check without even realizing it
Yeah again, there is even a TODO comment relating to that exact problem, the fact that it isn't perfectly efficient.
Or rather, wasn't. I commit this https://github.com/rlaphoenix/nton/commit/8925b0fa8b2f68267e7c3c4797b762c548f1aa9b which checks by looking for Nintendo & switch folders, or atmosphere & bootloader (hekate) folders. This will be quite a bit more efficient, enough to remove that TODO comment, but even still it has holes. E.g., a completely blank SD that they are preparing via packs and then trying to do forwarders with.
The reason it didn't work is because "path.drive" already includes the colon, so "{path.drive}:/" ended up with two colons and didn't match the replace.
It's kind of strange how this has only begun to be a problem recently. I could have sworn this code was tested working and all. It's old code even, from versions back. Strange stuff.
admiralspeedy
commented
1 year ago What I mean is have the command something like these examples:
nton build --name "Homebrew Menu" --nro "C:\...\hbmenu.nro" --sdmc "/"
nton build --name "Edizon" --nro "C:\...\edizon.nro" --sdmc "/switch/Edizon/"
I mean yah, there is some redundancy but if you're forced to set both paths manually then you don't have to make any assumptions or do any weird transformations to the NRO path, or try to figure out of it's an SD card or not. All you have to do is take the specified sdmc path and place the NRO file name at the end of it.
I have used tons of applications that require you to specify two similar paths, it's just for sanity really. I'm all for making it easier for people but also even the documentation on the paths is confusing. The "H:/hbmenu.nro" example in the readme actually confused me for a bit last night because I wasn't sure if I was supposed to be putting a drive letter or what the example was really trying to say.
rlaphoenix
commented
1 year ago That's only slightly less repetition though. I'd find that very annoying to do personally. Like think about it. Here's why it's just more work:
Overall it's just more work in terms of remembering, figuring out, and possibly renaming the NRO if we do your relative sdmc method. Which then brings in the guessing/remembering problems again, for the NRO filename.
EDIT: Another issue that gets brought up by not explicitly using the NRO on the microSD card, is that you may or may not be using the correct NRO on your PC that you have on your microSD card. This may lead to incorrect values on your generated NSP in regards to Icon (if it changed) or Version, or other general NACP stuff.
admiralspeedy
commented
1 year ago I think we'll have to agree to disagree on this one, but it is your software and you are free to write it as you wish. I appreciate that it even exists though.
I will try the resulting NSP with the new ExeFS ROM and let you know how it goes.
admiralspeedy
commented
1 year ago The path thing fixed it, NSP works now and I tried with the new ExeFS ROM and it does work, homebrew closes now without crashing (although, back to the home screen instead of the Homebrew Menu, but that's fine).
rlaphoenix
commented
1 year ago Fantastic news :)
Describe the bug I made a forwarder for Homebrew Menu with a clone of the latest repo to see if the new ExeFS ROM fixed the homebrew exit bug. it was created fine and installs fine on my Switch, but when I try to launch it I get the Nintendo Switch loading logo, followed by "The software was closed because an error occurred."
To Reproduce Steps to reproduce the behavior:
Expected behavior The Homebrew Menu should launch,
Additional context I have read the readme several times to ensure I didn't miss anything. My prod.keys are up to date, I literally dumped them from 16.0.2 tonight. I am running AMS 1.5.2 and my sig patches are up to date, as I generated them myself with the IPS tool from my own 16.0.2 firmware dump and the AMS 1.5.2 package3 binary. I also can confirm that my sigpatches are valid and working because I can use the pre-built forwarder linked in the latest release without issue.
I also rolled back the ExeFS ROM files to see if this was an issue caused by that commit, but I still have the same issue.
Here is the crash log from AMS, and the generated NSP: 01681872573_010d6fd3b35cd000.log Homebrew Menu v3.5.1 by switchbrew [010d6fd3b35cd000].zip