Can they coexist with each other? I want to use some A9LH payloads that aren't available with B9S 1.3 (like Emunand9). Having to downgrade B9S every time I want to use one of these A9LH converted payloads is a real hassle. I notice that the SafeB9SInstaller deletes the current A9LH installation by default. Is there any way to have both of them working?
Hacking Is there any way to have both A9LH and B9S installed?
- Thread starter ArmoredGuns1
- Start date
- Views 2,030
- Replies 18
It's not possible to have both running at the same time since they both install relevant parts into NATIVE_FIRM partitions.
If you're adamant on using emunand9 (which is redundant nowadays since godmode9 offers pretty much the same functionality), try converting it into a B9S payload using firmtool.
If you're adamant on using emunand9 (which is redundant nowadays since godmode9 offers pretty much the same functionality), try converting it into a B9S payload using firmtool.
D
Deleted User
Guest
He WAS using firmtool. It was never updated to work with 1.3 conversions, check the Github.
That said, OP there is no reason to use outdated programs. If the devs themselves didn't update them to work with B9S they themselves have quit the scene or they deemed it unnecessary since other tools available do the same thing. EmuNANDs themselves are outdated, so most programs dropped support (or hid it unless it's being run FROM an emuNAND). If you REALLY want one, just use a PC tool like 3DS Multi-EmuNAND Creator; despite the name you can only create one if you want.
D
Deleted User
Guest
Yes you can.. An app could still brick MCU. This is currently considered unrecoverable because the MCU not only controls the leds but the power button. NTRboot can fix all other bricks with a simple flashcart and a backup, but definitely not a MCU brick. Someone could quite easily design a malicious cia file to do this, as there is already apps that can modify the MCU.
D
Deleted User
Guest
The MCU SoC busses control a lot more than just the LEDs and the Power Button. They also control the camera, volume slider, home button, the LCD, accelerometer and more... That's a big reason a lot of people with simple hardware failures think they bricked; when normally if one of those things is corrupted via cable/hardware you're only ever going to get a blackscreen on boot until it's repaired.
I think you can run a9lh payloads from godmode9. So if you wanted to run an a9lh payload you would boot into godmode9 and then boot the desired payload.
Nope. GM9 won't run .bin files. But it will run converted payloads -- Gateway, AGBSave9, and EmuNAND9 (no luck with Puma) run just fine. Just copy the .firm files you want to run to the "gm9/payloads" folder and they'll show up on the "Payloads" menu. BootCTR9 seems to run .bin payloads just fine, though (will even run Puma). Actually, even CBM9 can run AGBSave9 and EmuNAND9. Luma's chainloader is just garbage. It can't even run Cakes until you launch it with BootCTR9 or CBM9 first (I tried making my CakesLauncher script an SSR, and it still wasn't enough).
I think you mean 1.2 (aka that attempt by the Luma team to pull a "GW Fastboot" and cut everyone else out of the picture). 1.3 broke nothing. Actually the example given by the firmtool readme still works (I would add "-i" for good measure -- screen init). Here's the thing. They work in BootCTR9 and GM9. The text mode ones even work in CBM9. Luma's chainloader is the only thing that chokes on these, so I think it's the problem. Why use it? Just use BootCTR9. It's always been the best chainloader hands down. Or replace B9S with GM9 and have a good chainloader built right into your firm (if d0k3 ever adds hotkeys, there will be no need to have boot.firm include a chainloader at all). Besides, scripts menu at boot, FTW
Last edited by Kazuma77,
No I meant firmtool conversions don't work with v1.3 of B9S; nothing more.Nope. GM9 won't run .bin files. But it will run converted payloads -- Gateway, AGBSave9, and EmuNAND9 (no luck with Puma) run just fine. Just copy the .firm files you want to run to the "gm9/payloads" folder and they'll show up on the "Payloads" menu. BootCTR9 seems to run .bin payloads just fine, though (will even run Puma). Actually, even CBM9 can run AGBSave9 and EmuNAND9. Luma's chainloader is just garbage. It can't even run Cakes until you launch it with BootCTR9 or CBM9 first (I tried making my CakesLauncher script an SSR, and it still wasn't enough).
I think you mean 1.2 (aka that attempt by the Luma team to pull a "GW Fastboot" and cut everyone else out of the picture). 1.3 broke nothing. Actually the example given by the firmtool readme still works (I would add "-i" for good measure -- screen init). Here's the thing. They work in BootCTR9 and GM9. The text mode ones even work in CBM9. Luma's chainloader is the only thing that chokes on these, so I think it's the problem. Why use it? Just use BootCTR9. It's always been the best chainloader hands down. Or replace B9S with GM9 and have a good chainloader built right into your firm (if d0k3 ever adds hotkeys, there will be no need to have boot.firm include a chainloader at all). Besides, scripts menu at boot, FTW
Yes they do. I have made changes to CBM9's .bin file and converted it to a .firm (I wanted the config file out of the root). It works with v1.3 of B9S completely. It will boot on it's own, and chainloaders have no errors running it. Luma even likes it for some reason (if I could figure that one out, I'd have it running GW). Actually, I have got Luma to run GW, EmuNAND9, and AGBSave9 on a fresh card, but it won't do it anymore once you've booted Luma to the home menu. I'm starting to think it has a blacklist or something.
Last edited by Kazuma77,
Oh ok, I just assumed all the failed attempts in the firmtool thread along with the last release (as branded as being compatible with B9S v1.2) implied that the tool wasn't updated to handle v1.3 firms. If there is no difference between 1.2 and 1.3 in regards to the .firm build of course they'd work Lol. Though IMO most of those programs that weren't updated by the devs themselves are useless. I definitely second the advice to use BootCTR in any case, I really like my boot animations.
I can agree with that. Wanting to keep GW working, sure. AGBSave9, well, it is just D9's AGB save functions ripped to a separate app, but it does go straight to it. EmuNAND9, Hourglass9, and Uncart probably aren't worth it. I converted EmuNAND9 just because it could do legacy EmuNANDs, but I've had issues with GM9 not recognizing partitions on EmuNANDs formatted using EmuNAND9 (considering dropping it from my AIO at this point). I'd recommend either using the original GW software or GM9 (and GM9 is probably better for 256 GB or larger cards, since they need to be formatted as 64K apparently).
As per the OP's post though, InScripted does include exploit switching scripts. They're pretty much just mini installers that do the install, then swap out chainloader files so the system will still boot. It's not exactly having both installed at the same time, but it lets you switch back and forth pretty quickly (though I only do it for testing purposes, like seeing what I can get working with OldLoader, speaking of which, I still need to compile a copy for Rei-Six and see if it works). They're a pretty fast way of going back and forth. But I had run out of practical reasons to do it before I even had the scripts written. I had already managed to get everything I needed to work with B9S. I just made them out of curiosity mostly. Though I have a new trick I'm working on for the next release -- switching Sighax firms. This one uses "filesel" so it's expandable (I just give the configuration folders names like "boot9strap.firm.config" for example, so that the selected file can be used to determine what chainloader configuration is used). It's proving quite useful. The only downside is that "boot9strap" has become a permanent folder (but it's not like it eats that much space). I could move it, I just haven't for BC with SB9SI
Last edited by Kazuma77,
- Joined
- Nov 23, 2014
- Messages
- 15,144
- Trophies
- 0
- Location
- Canberra, Australia
- Website
- boot9strap.com
- XP
- 11,094
- Country
D
Deleted User
Guest
I personally up my NAND backups to a private Mega account. It's part of my weekly maintenance I do every Saturday night and has helped me get out of a lot of issues before.
Honestly unless the OP is doing some serious testing that could brick their system, I don't really suggest emuNANDs anymore. And even then, with NTRBoot being a thing, there's even less of a reason to keep using an emuNAND.
There's also no reason to keep using emuNAND9 if you are only maintaining one emuNAND. Just make a clone with GodMode9 and keep that backed up.
Similar threads
