problem with wup install mod y

[lyokohack]

I did the tiramusu hack, and when I want to install a game with wup install mod y the game installs but I'm blocked by my mii editor, can this error be countered by a manipe?

wup install gx2 works, but I prefer mod y

 

[Hayato213]

use gx2

 

[mrmagicm]

I Recommend to Use NUSPLI 1.130 (no time wait when you install a wup via SD card, no SD space check).
After the next version, the check cannot be set to "disabled", so that is a big load of time when you have a big sd card and you make many tests. The fact that when you push the home button, it directly exits is better than Wup installer
I also like the "no update option" in the menu, very nice! I use 1.130 for quick install in front menu and the newest version in HBL.
Sometime, I wonder if wup installer/ Wup installer mod y/Nuspli have been tested to install wup forwarders correctly because when I install some Forwarders I made and tried to test (loadiine and retroarch), they don't work properly, they don't work...is it the creation, the fact that they are RPX/Elf ....OR is it coming from the Wup installers that don't give them maximum sigpatch/mocha rights. I'm wondering....

 

[V10lator]

I Recommend to Use NUSPLI

^- This! No matter if Y-Mod or GX2, both use outdated methods and Y mod not working as intended on Tiramisu is just one of many sympthoms of this.

I btw didn't reply more early as to not make it look like shameless self advertising. I wanted to wait till somebody other mentions NUSspli before stepping in. ^^

so that is a big load of time when you have a big sd card

It's 60 seconds max and for that you have to be fast navigating NUSsplis menu as the check is async and done as early as possible. So in reality it is a bit annoying but a minor issue. Also it's a one-time check, so if you build up a queue of games to download the waiting time will be with the first game only. There's a lot of caching and other coding tricks involved to make this as smooth as possible (read: We coded for weeks to make this as smooth as possible) for you but the ultimate fix would be to completely replace the FAT32 driver of IOSU. A task some people tried but nobody managed to do yet.

Anyway, multiple bugs have been fixed since v1.130 so I would highly recommend to update to the latest version! Also you're kicking yourself out of the support zone with using outdated versions (for example the reason the red error screens show the NUSspli version is so that we, the devs of NUSspli, see an outdated version in case someone uploads a screenshot. So we don't have to waste time with this but we can just say "upload to newest version and tell us if this fixed the issue". )

Back to topic / to the OP: Use NUSspli (Lite) instead of WUP Installer. The Lite version doesn't have the download option in case you're concerned about this. So NUSspli Lite is nothing more than a modernised WUP Installer.

 

[mrmagicm]

@V10lator
Is there no way to make the Check in Nuspli "optional" by setting it to disable? Also, do you know if Nuslpli works perfectly for installing all forwarders? Before, I had my loadiine forwarder working fine with an old version of Loadiine (2017 version I think), but since I updated mocha or sigpatch file, the forwarder seems to be not working know, is that relevant to you? I mean, do you think the forwarder is created to work with particular mocha/sigpatch or tiramisu version/ loadiine version? Or could Wup installer or nuspli installers aren't pefect with forwarders? A bug seems to be somewhere but I'm not sure of anything. I know forwarders are not important to many but....
Also, I use latest Nuspli when 1.130 wouldn't work but it always work, never had a pb with nuspli since file system of tiramisu are "updated" (by this I mean payload.elf , mocha, sigpatch) from time to time.
nice info about the Fat 32 driver : You should make publicity for someone carring enough to fix the FAT32 driver of IOSU in you forum page of Nuspli as it's seems very specific knowledge.

 

[V10lator]

Is there no way to make the Check in Nuspli "optional" by setting it to disable?

https://gbatemp.net/threads/should-nusspli-have-an-option-to-disable-the-free-size-check.645001/

Or could Wup installer or nuspli installers aren't pefect with forwarders?

Both, WUP Installer and NUSspli, don't do installations. Sounds wrong? Well, the eShop also doesn't do installations. Instead there is a program called MCP running on the Wii U. It's kind of a master process doing security relevant tasks and other stuff. This MCP does the installations: WUP Installer, NUSspli and eShop just tell MCP where to find the files, on which media to install them (NAND or USB) and other metadata, then they start a loop in which they ask MCP for the current state and process the reply to i.E. show a installation bar, react to errors and stuff.

So chance that NUSspli is the culprit is pretty low. Note that there is still a small chance: NUSspli changes tickets on the fly if needed. For example older Teconmoon releases had a small error in their tickets, so NUSspli fixes that in case it detects such a ticket. Do you still have the original files of the injector befor installing it through NUSspli? If so compare the tickets (just take checksums) before and after installation. In case they differ DM me.

A bug seems to be somewhere but I'm not sure of anything.

This bug is known to many people. It's the CFWs (Tiramisu/Aroma) itself. You even seem to have pinpointed it to the mocha payload now (pretty sure it's not the sigpatches module as that just does exactly what Haxchi and Mocha did but I'll compare codes again next days to make sure).
The bug is GCN (and maybe Wii?) injectors black screening, correct? So the Wii U reboots as it shoulds, gamepad shows the Wii logo but then the game won't load but you'll just have a black screen.

Sadly this bug has been reported multiple times to the CFW devs but they just say it is impossible that a Wii U CFW interfers with vWii... We clearly see it is possible (this bug itself is the proof, no?) and there are things like c2w which clearly connect Wii U and vWii side. In fact one of the CFW devs (Gary) wrote an Aroma plugin which changes vWii stuff ( https://github.com/GaryOderNichts/evwii ), so they know it is possible but oh well...

Anyway, normally the fix for the bug is to simply reinstall the blackscreening injectors. Not sure why this won't work for you.

//EDIT: To reinstall a injector correctly you have to uninstall it in Wii Us data management first or simply use NUSspli, it will uninstall before reinstalling automatically. Such stuff (this auto-uninstall or the on the fly ticket fixer) are btw what I mean when I sometimes make statmenets like "NUSspli fixes bugs you didn't know they existed".