Hacking Neek2o Stuck on "Reloading bootmii IOS"

[TapsofOsiris]

I found a great tutorial by Abz that I followed exactly. After Neek2o was installed I ran the forwarder from system menu but it got stuck on "Reloading bootmii IOS". I read that the first boot takes a while so I let it sit for 15 mins with no luck. I then setup Neek2o with the fantastic ModMii program by Xflak. I have tried using both a USB HDD (FAT32-32k) and an SD (FAT32-32k), Nand dump and fresh nand, with no luck. I also tried booting from HBC also but a black screen hangs forever, I even waited as long as 30 minutes with nothing happening even on a nand with no wads pre-isntalled. An old thread mentioned verifying "emuNAND path setting", but I have no clue how to do that. Any insight or help with my issue will be greatly appreciated. I'm fairly new to the Wii scene in general so please excuse my general derpy-ness when posting here. Thanks in advance.

 

[FancyNintendoGamer567]

For UNEEK, I fixed my problem by copying the SD bootmii folder to my USB, however it may not work for other people.

 

[Cyan]

either you forgot a step, either the guide is not that "great" and just assume all people have similar setups.
To launch neek, you need multiple things.


First, to understand how it's launched :

At console boot, with bootmii@boot2 capable Wiis:
console Power > Boot0/1 > Boot2 > sd:/armboot.bin > sd:/sneek/kernel.bin > switch to another partition? > partition:/sneek/kernel.bin > partition:/emuNAND path/

With non Bootmii@boot2 Wiis (or boot2 not installed), using nswitch channel or homebrew
nswitch > Bootmii IOS > sd:/armboot.bin > sd:/sneek/kernel.bin > switch to another partition? > partition:/sneek/kernel.bin > partition:/emuNAND path/


with USBLoaderGX: (either bootmii@boot2 installed or not)
partition:/sneek/kernel.bin > partition:/emuNAND path/


What you need


1. bootmii !
1.A bootmii launcher
either bootmii installed as boot2, and neek will be launched at console's boot.
either bootmii installed as IOS, and neek will be launched manually (from a channel, or hbc). if you have a "stub" IOS Slot254 it CANNOT LAUNCH NEEK
run syscheck to verify if you have bootmii installed in slot254 !

1.B bootmii armboot.bin
rename the "bootmiineek" folder to "bootmii" and put on SD card.

if you miss either the bootmii launcher, or the neek's armboot.bin in bootmii folder, it will stay indefinitely on "rebooting to bootmii" because ... you miss bootmii !


2. sneek on SD
whether you want sneek or uneek, you always need the /sneek/kernel.bin on your SD card.
kernel.bin need to be the one corresponding to where your emuNAND is located.
sneek's kernel.bin if emuNAND on SD.
uneek's kernel.bin if emuNAND on USB.

3. sneek on destination partition
if your emuNAND is on SD, put the "font.bin" in sd:/sneek/

if your emuNAND is on USB, you need ADDITIONAL (not exclusive!) files on USB :
usb:/sneek/kernel.bin <--- this need to be BOTH on SD and USB.
usb:/sneek/font.bin


4. your emuNAND folder :
if you use neek (not neek2o) emuNAND should be on root.
if you use neek2o, emuNAND should be is 2 subfolders. example : sd:/nands/my_nand/
sd:/nand/ <-- not enough
sd:/nand/pl_us/ <-- good
sd:/nands/01/ <-- good

5 disc interface
if you want to play disc games from neek(2o) you need to put "di.bin" in the sneek folder where you have your emuNAND path. (sd:/sneek/ for path on Sd, usb:/sneek/ for path on usb)



6 if you use USBLoaderGX as neek launcher, you can skip the "step 1" or "step 2"
USBLoaderGX doesn't rely on bootmii at all, and therefore can loads the kernel.bin directly from the same partition than your emuNAND folder.
Additionally, it can live with both Sneek and Uneek installed at the same time, and boot the proper one based on the path to your emuNAND.

 

[TapsofOsiris]

if you miss either the bootmii launcher, or the neek's armboot.bin in bootmii folder, it will stay indefinitely on "rebooting to bootmii" because ... you miss bootmii !

First of all, thanks for taking the time to write such a detailed explanation of how SNEEK works. I needed the insight. I was hoping it was an issue with my file placement but now I think there's something weirder going on. Here's why: Regular bootmii works fine if launched directly from HBC when original bootmii armboot.bin is used in SD:/bootmii, but when the SNEEK-DI armboot.bin is placed in SD:/bootmii and launched with HBC it hangs on black screen indefinitely. How can I miss bootmii if I'm launching it directly from HBC? I'm Sure it's something that I did or am doing wrong but I can't wrap my head around it.

I verified that bootmii is installed on IOS 254, but maybe there's something else wrong with my system. Everything is up to date according to ModMii but here's my syscheck. Pease help I'm stumped.

SysCheck HDE v2.4.0 HacksDen Edition by JoostinOnline, Double_A, R2-D2199, and Nano
...runs on IOS58 (rev 6176).

Region: NTSC-U
System Menu 4.3U (v513)
Priiloader installed
Drive date: 12.18.2008
Homebrew Channel 1.1.2 running on IOS58

Hollywood v0x21
Console ID: 141816679
Console Type: Wii
Shop Channel Country: United States (49)
Boot2 v4
Found 78 titles.
Found 53 IOS on this console. 4 of them are stubs.

IOS3 (rev 65280): Stub
IOS4 (rev 65280): Stub
IOS9 (rev 1034): No Patches
IOS10 (rev 768): Stub
IOS11 (rev 16174): Trucha Bug, NAND Access
IOS12 (rev 526): No Patches
IOS13 (rev 1032): No Patches
IOS14 (rev 1032): No Patches
IOS15 (rev 1032): No Patches
IOS16 (rev 54321): Trucha Bug, ES Identify, Flash Access, NAND Access
IOS17 (rev 1032): No Patches
IOS20 (rev 16174): Trucha Bug, NAND Access
IOS21 (rev 1039): No Patches
IOS22 (rev 1294): No Patches
IOS28 (rev 1807): No Patches
IOS30 (rev 16174): Trucha Bug, NAND Access
IOS31 (rev 3608): No Patches
IOS33 (rev 3608): No Patches
IOS34 (rev 3608): No Patches
IOS35 (rev 3608): No Patches
IOS36 (rev 3608): No Patches
IOS37 (rev 5663): No Patches
IOS38 (rev 4124): No Patches
IOS40 (rev 16174): Trucha Bug, NAND Access
IOS41 (rev 3607): No Patches
IOS43 (rev 3607): No Patches
IOS45 (rev 3607): No Patches
IOS46 (rev 3607): No Patches
IOS48 (rev 4124): No Patches
IOS50 (rev 16174): Trucha Bug, NAND Access
IOS51 (rev 4864): Stub
IOS52 (rev 16174): Trucha Bug, NAND Access
IOS53 (rev 5663): No Patches
IOS55 (rev 5663): No Patches
IOS56 (rev 5662): No Patches
IOS57 (rev 5919): No Patches
IOS58 (rev 6176): USB 2.0
IOS60 (rev 16174): Trucha Bug, NAND Access
IOS61 (rev 5662): No Patches
IOS62 (rev 6430): No Patches
IOS70 (rev 16174): Trucha Bug, NAND Access
IOS80 (rev 16174): Trucha Bug, NAND Access
IOS90 (rev 54321): Trucha Bug
IOS202[60] (rev 65535, Info: hermesrodries-v6): Trucha Bug, NAND Access, USB 2.0
IOS222[38] (rev 4, Info: hermes-v4): Trucha Bug, ES Identify, NAND Access, USB 2.0
IOS223[38+37] (rev 4, Info: hermes-v4): Trucha Bug, ES Identify, NAND Access, USB 2.0
IOS224[57] (rev 65535, Info: hermesrodries-v6): Trucha Bug, NAND Access, USB 2.0
IOS236 (rev 54321): Trucha Bug, ES Identify, NAND Access, Beer Ticket
IOS247[37] (rev 21006, Info: d2x-v6): Trucha Bug, NAND Access, USB 2.0
IOS248[56] (rev 21006, Info: d2x-v6): Trucha Bug, NAND Access, USB 2.0
IOS249[57] (rev 21008, Info: d2x-v8final): Trucha Bug, NAND Access, USB 2.0
IOS250[56] (rev 21008, Info: d2x-v8final): Trucha Bug, NAND Access, USB 2.0
IOS254 (rev 65281): BootMii
BC v6
MIOS v10
Report generated on 03/21/2019.

 

[Cyan]

your bootmii IOS is properly installed (not stub).
your armbootbin is correctly replacing original's bootmii's file (not located in "bootmiineek" generated by modmii)

but when the SNEEK-DI armboot.bin

you have "di.bin" in your sneek folder?

di.bin is used to redirect disc interface to external drive.
but in order to work, it requires at least 1 game disc on that external drive. if you don't have at least one, it'll be stuck on black screen at neek launch.

be sure to remove the "di.bin" from your sneek folder to first be sure neek is working fine without it. once everything is working, you can add it back to see if "di" works, and focus on fixing it.

 

[TapsofOsiris]

di.bin is used to redirect disc interface to external drive.
but in order to work, it requires at least 1 game disc on that external drive. if you don't have at least one, it'll be stuck on black screen at neek launch.

be sure to remove the "di.bin" from your sneek folder to first be sure neek is working fine without it. once everything is working, you can add it back to see if "di" works, and focus on fixing it.

Okay thanks for the tip. Now it only loads without di.bin in the sneek folder. Progress was made at least, but why won't di.bin recognize my games?

This is the file structure on my drive:

Wii games - USB:/wbfs/game name [title id]/title id.wbfs (i.e., USB:/wbfs/Okami [ROWE08]/ROWE08.wbfs)

GC games - USB:/games/game name.iso (i.e., USB:/games/Baldur's Gate - Dark Alliance.iso)

I used Wii Backup manager to transfer my Wii backups and manually transferred my GC isos. Should my wbfs format games be in the "games" folder too?
Or maybe It needs isos instead of wbfs, Wii Backup Manager converted them automatically.

 

[TapsofOsiris]

I meant to say why won't SNEEK with di.bin recognize my games?

 

[Cyan]

I think di.bin redirects the disc interface to the same device used by neek.
if you use sneek (SD), then it looks into sd:/wbfs/
if you use uneek (USB), then it looks into usb:/wbfs/


Edit2021:

I think the original Neek (not 2o) is always trying to load the extracted games from USB:/games/
If you are using neek instead of neek2o, be sure to put games on USB.
It might be the same for neek2o, looking only at USB, so if you put on SD and it doesn't work, try putting games on USB even if you are using Sneek2o.

initially (before neek2o with wbfs support), di.bin looked for extracted game format into the /games/TitleID/ folder and expected the game to be extracted in a specific folder name using DiscEX(traction) tool from Crediar.
if you had di.bin in sneek folder, but didn't at least put one extracted game into the /games/ folder in correct format, then sneek wouldn't launch.
that's one of the issue most people had : they wanted everything setup directly with all possible options (including di.bin), but without having properly prepared SD/USB content, and resulting in neek not booting.

I always suggest users to first be sure neek works fine without di.bin, to know if the issue is di or their setup.
once neek is known to work, then you can look into making di work too.


either try uneek2o+di (to see wbfs on your usb), or try to put a wbfs folder (empty ? with at least a game?) on SD card too.
if it boots with empty wbfs folder, or with at least one game on SD, then try pressing 1 (or 2? I always forget) to access the "mount game" menu. select the wbfs game to mount into the Disc channel, and try to launch it.
if it works, you'll know the games are looked on the same partition than emuNAND folder. you should then use Uneek2o to have access to all your games. or just put non working games on SD card (like Tintin, We dare, Drivers SF, etc.), they can't be played from USB Loaders anyway.

 

[NormalMisha]

either you forgot a step, either the guide is not that "great" and just assume all people have similar setups.
To launch neek, you need multiple things.


First, to understand how it's launched :

with bootmii@boot2:
console Power > Boot0/1 > Boot2 > sd:/armboot.bin > sd:/sneek/kernel.bin > switch to another partition? > partition:/sneek/kernel.bin > partition:/emuNAND path/

with nswitch channel or homebrew
nswitch > Bootmii IOS > sd:/armboot.bin > sd:/sneek/kernel.bin > switch to another partition? > partition:/sneek/kernel.bin > partition:/emuNAND path/


with USBLoaderGX
partition:/sneek/kernel.bin > partition:/emuNAND path/


What you need


1. bootmii !
1.A bootmii launcher
either bootmii installed as boot2, and neek will be launched at console's boot.
either bootmii installed as IOS, and neek will be launched manually (from a channel, or hbc). if you have a "stub" IOS Slot254 it CANNOT LAUNCH NEEK
run syscheck to verify if you have bootmii installed in slot254 !

1.B bootmii armboot.bin
rename the "bootmiineek" folder to "bootmii" and put on SD card.

if you miss either the bootmii launcher, or the neek's armboot.bin in bootmii folder, it will stay indefinitely on "rebooting to bootmii" because ... you miss bootmii !


2. sneek on SD
whether you want sneek or uneek, you always need the /sneek/kernel.bin on your SD card.
kernel.bin need to be the one corresponding to where your emuNAND is located.
sneek's kernel.bin if emuNAND on SD.
uneek's kernel.bin if emuNAND on USB.

3. sneek on destination partition
if your emuNAND is on SD, put the "font.bin" in sd:/sneek/

if your emuNAND is on USB, you need ADDITIONAL (not exclusive!) files on USB :
usb:/sneek/kernel.bin <--- this need to be BOTH on SD and USB.
usb:/sneek/font.bin


4. your emuNAND folder :
if you use neek (not neek2o) emuNAND should be on root.
if you use neek2o, emuNAND should be is 2 subfolders. example : sd:/nands/my_nand/
sd:/nand/ <-- not enough
sd:/nand/pl_us/ <-- good
sd:/nands/01/ <-- good

5 disc interface
if you want to play disc games from neek(2o) you need to put "di.bin" in the sneek folder where you have your emuNAND path. (sd:/sneek/ for path on Sd, usb:/sneek/ for path on usb)



6 if you use USBLoaderGX as neek launcher, you can skip the "step 1" or "step 2"
USBLoaderGX doesn't rely on bootmii at all, and therefore can loads the kernel.bin directly from the same partition than your emuNAND folder.

Based on your three possible routes to booting an EmuNAND, it seems that if you want to be able to boot it manually only (via a channel), that's not possible. Because to do that you need to alter bootmii's armboot.bin file and therefore every time the console boots, bootmii will boot into your EmuNAND. Is that right? Something seems odd about that to me. I must admit I don't fully understand what bootmii's default armboot.bin file is/does. Presumably it contains code which looks at the ini file and boots what the ini file tells it to boot, which by the looks of it is only ever the System Menu or the Homebrew channel.

Anyway, that's the setup I want. I just want to be able to boot my EmuNAND manually via a channel that exists on my real NAND. I'd be surprised if that was an uncommon requirement. So is it possible that there is some kind of typo in your three routes explanation?

Thanks,

Misha

 

[Cyan]

three possible routes to booting an EmuNAND

3 routes to boot Neek(2o). But if you just want emuNAND, there are other, easier, solutions with cIOS.


If you have bootmii@boot2, boot2 loads armboot.bin from SD.
armboot.bin IS bootmii, and is the one checking the ini file, checking the countdown delay, what to boot, and video mode.

So, you are right, if your Wii is bootmii@boot2 capable, it would always boot it at launch if you replace bootmii's armboot.bin with neek's one.
I edited my guide above to properly explain that the 2nd solution requires a NON @boot2 wii.
I guess most users don't have a boot2 capable wii, therefore it never checks that file at boot, and they can rely on it by launching armboot.bin manually (either bootmii, or neek) from HBC or from Nswitch homebrew.

There is a channel to boot Neek; you need the Nswitch channel. I never tried it on my @boot2 wii.
The one I know is very old, and relies on armboot.bin located in bootmii folder.

I know Nswitch on vWii can boot neek without relying on bootmii, and (the old version of Nswitch) it checked the console type and used either bootmii, or not.

Seeing it could boot without bootmii, I tried the same vWii method on Wii and it worked. Therefore I used the "non bootmii" solution inside USBLoaderGX, which can boot neek without replacing the armboot.bin file.
That feature is unfortunately not bootable from a channel (using argument to autoboot a game using USBGX for example), as it doesn't launch any TitleID.


But, I know OverJoy worked on Nswitch and updated it heavily ! I just don't know what has been done for the past 2 years.
I think it has menus, and options, and different possibilities. I hope it now always use the vWii method on both Wii and vWii.
I also don't know if it's publicly released, sorry. I just heard about it being updated.

If you can't find the new version, you'll have to boot neek using USBGX's features menu if you don't want to autoboot neek at console launch.


A solution using a Channel with @Boot2 Wiis would be to "hack" existing methods to make it launches into neek's sysmenu manually.
I guess you would use Neek2o, with both Autoboot (launch a channel's at neek launch, bypassing sysmenu) and returnto (reload a channel at game exit instead of sysmenu) features.

- setup neek
- add a fake channel TitleID on neek (something like a channel with a homebrew which just exits and return to Sysmenu !!) main(){ video_init; exit; } <-- something like that. could be titleID "EXIT" ? I'm sure there are already homebrew loading sysmenu, you just need to inject it into a channel with TitleID of your choice.
- setup usbgx with neek
- setup USBGX to disable "return to" for that channel. (it's in the individual game settings), so it doesn't reload to another channel in order to return to sysNAND when the "fake channel" exits to neek's sysMenu.

- Create a WiiGSC channel, booting the fake neek channel TitleID using USBGX, and install it to your sysNAND.

Now, you can run your channel, which will launch USBGX, which will autoboot (no GUI) that emuNAND channel located on neek. Neek will boot, launches the channel which loads (exits to) neek's sysMenu.....


Note :
If you use Neek (NOT neek2o), it doesn't have autoboot features.
I don't remember if I placed a warning in USBGX at channel boot saying it won't work, or if it just launches it anyway and just loads neek's sysmenu. You wouldn't need that fake "exit" channel.
That's an easier solution, but you'll have only the old neek, not neek2o features.



Note2:
Another solution would be to edit the old Nswitch to always use vWii method, recompile and install that one as a channel.
Depending on your experience in development, you could choose either that method, or the non dev method with WiiGSC.