Luma3ds: CTRBoot Manager + Luma3DS not work

[EightyVI]

Sorry for my english.

Luma + CTR isn't working.
Within the CTR configuration file is a "Luma3DS.dat", so it never starts.

{ title = "Luma3DS"; path = "/Luma3DS.dat"; offset = "0x12000"; },

We must change the configuration, to realize the execution of "Luma3DS.3dsx".

{ title = "Luma3DS"; path = "/3ds/Luma3DS/Luma3DS.3dsx"; offset = "0x12000"; },

I hope it helps.
Regards.

[Margen67]

There's the problem; You're using menuhax.
You need to switch to B9S.

[TuxSH]

Luma3DS.dat is located in the mset-spider folder of release archives.

[EightyVI]

A9HL bla bla bla bla.....

To all who know how to use emunand, we do not care that the console starts in less than 10 seconds.
We prefer to work safely on a emunand, instead of running some risk of bricking in sysnand.

Location of Luma3DS.dat, and we know it all, this particular problem is given in this new version 6.5.1.

I'm simply trying to help all those who encountered this problem, forcing them to launch Luma3DS from Homebrew Launcher.

Regards.

[Margen67]

A9HL

lol

We peasants prefer to settle on a waste of SD card space instead of running some risk of mah brixxxxx.

The only way of bricking with A9LH Updated SysNAND is if you overwrite firm which you have to TRY to do.
As for Plailect's guide the only real risk is user error.
If anything is unsafe it's menuhax since SysNAND can still be updated or bricked without any way to recover.

[cheatfreak47]

@EightyVI You can't brick SysNAND A9LH as long as you have a backup sitting around somewhere.
Luma3DS protects the SysNAND Native Firm (firm0/1) from being written to after it boots, thus preventing any potential hard bricking that could happen. If you can manage to hardbrick after that, it'd have to be a total hardware failure or a deliberate attempt at bricking the console.

In addition, Arm9LoaderHax provides immediate access to code execution on the Arm9 Security co-processor, whereas each time you load menuhax, an unstable memory exploit has to run successfully in order for the a proper boot to happen. On top of this, EmuNAND has several negatives, such as it's inability to run DSiWare or GBA titles without a simultaneous SysNAND install. (Which defeats the whole "I don't wanna brick sysNAND" argument because you're installing crap to the SysNAND anyway to overcome a legitimate shortcoming of EmuNAND.)

Frankly, I don't have a problem with your using MenuHax with Luma, I'm saying that your reasons for justifying sticking with outdated software are flawed.

If you wanna stick to something inferior, at least don't make up stupid justifications for it.
Just say "I'm lazy and I don't feel like setting it up" and move on. If you did that, people like Margen and I wouldn't get on your ass about it.

---

Edit: Also, this is not an issue with Luma3DS at all actually, the issue is with user configuration, which falls under user support for your boot manager. Luma has nothing to do with this.

[EightyVI]

We understand how it works and the benefits of A9HL, the probability of a possible brick is always present, even if the NF is protected.
No problems when nands are linked.

For most use MenuHax may be outdated, but still there are people who still used.
[(https://github.com/AuroraWright/Luma3DS/issues/267)]

I just gave you a tip on how to fix the problem with this new version of Luma3DS.

Regards.

[Margen67]

We understand how it works and the benefits of A9HL

Clearly you don't since you can't even spell it right.

the probability of a possible brick is always present, even if the NF is protected.

If you're that paranoid then you shouldn't even turn on your 3DS since there's a chance that will brick it.

No problems when nands are linked.

Yes, there is. Did you not just read what cheatfreak said?
I thought you "understood how it works."

For most use MenuHax may be outdated, but still there are people who still used.

There are people that still use rxtools. Does that make it a good option? No.

[EightyVI]

Sacrilege by a typing error.
isn't paranoid, we prefer that emunand damage, instead of resorting sysnad and use Hardmod.
What he says cheatfreak, also installed in the sysnad by more than use A9LH, for GBA and DS use my DSL, I will not deny that use DSiWare or VC GBA, but not really use in my N3DS
rxtools know that is obsolete, the same situation happens to cakes. But menuhax remains functional.

[cheatfreak47]

@EightyVI The simple fact of the matter is you are wrong. There is no two ways around it.
You can't just respond to "2+2=4" with "No, 2+2=5! 👍" and expect to be looked at positively.
No matter what you say, you are arguing against actual proven facts, facts that have been infallibly proven by irrefutable evidence.

we prefer that emunand damage, instead of resorting sysnad and use Hardmod.

I don't know what you think the case is, but you don't need to hard mod to fix a bricked SysNAND with Arm9LoaderHax. Using the SysNAND doesn't damage it, I don't know where you get the idea that _using the system close to the way its intended to be used_ is somehow dangerous. Running a console with Arm9LoaderHax installed is literally like running a stock console. They are _in no way_ different outside of the gained unsigned code execution.

If you are afraid of running a stock console, then don't even use a 3DS.
News flash mate, other parts of the 3DS console wear out far _far_ faster than the NAND chip.
Statistically, you're likely to replace 4 circle pads before you experience the NAND chip failing on you.

On top of that A9LH can boot recovery tools that require code execution on the arm9 with a 100% consistent success rate, at boot time before the home menu loads. Decrypt9, Hourglass9, and even EmuNAND9 from the moment the console is powered on.

But menuhax remains functional.

First of all, _no, it doesn't._ It remains functional, because you've done nothing to break it.
It breaks incredibly easily. A single accidental update to the latest firmware on the SysNAND, and you lose everything.

While Arm9LoaderHax, has no such flaw, especially when you are running Luma with it.

Tell ya what mate, I'll level with you for a moment. You wanna know why you are wrong? This is why.
Let's play a little game I like to call...

What sounds safer to you?

Booting a stock 3DS, running a unstable memory exploit on the Arm11 with every single boot, and running an even more unstable Arm9 exploit, taking over a processor is a way it's not intended to work, and using that to soft reboot the console to load data from a port that it's not intended to load these things from, every single time the console boots, essentially booting the console twice each time you power on.

_or_

Exploiting the way the 3DS boots normally in a way gains unsigned code on the Arm9 and Arm11 at boot, without the need for the system to become unstable at any point at all due to the nature of the exploit and from there, booting into the console the way it's intended to run, but with CFW patches.

---

Hmm, it doesn't take a rocket scientist to see which one is not only safer and better in general.

I'm not trying to be mean here, but you're acting a fool by making justifications for real underlying issues.

You are lazy and you don't want to switch. And that's fine. You are free to do whatever you want.
But don't try to justify it with outright false statements. Own up to it.

[EightyVI]

@cheatfreak47 I'm n't against the use A9LH, put if it happens Nintendo launched an update of its FW corrupts the protection of A9LH and the same brick the console?
As at the time that add a blacklist for all cards.
I do not think so at this time because it is very late, and going to miss you are busy on other projects.
For me and others more, it is still safer to run an exploit, which overwrite an sysnand.

Thanks for the explanation.
Regards.

[cheatfreak47]

They can't, Luma protects it. It is literally impossible for them to patch it out. Luma 3DS protects it by the time the home menu has the chance to physically be able to do anything to it. It's more impenetrable than fort knox.

Also, Nintendo wouldn't be legally able to brick people. EULAs do not stand up in court, and they would likely be sued if they randomly decided to start remotely bricking consoles.

What if nintendo added a check for an EmuNAND on the SD Card at sysNAND boot and refused to even power on far enough for the console to run Menuhax until the EmuNAND partition is removed?

What if the world were made of pudding?

[TuxSH]

Well I didn't expect this to become like that (what @cheatfreak47 says is true, though)...