- Joined
- May 2, 2016
- Messages
- 449
- Trophies
- 0
- Location
- the deepest depths of hell.
- Website
- crimson.ninja
- XP
- 1,510
- Country
Yes, but this is a nightly. And is not linked on the guide. So most users likely dont use it.
Yes, but this is a nightly. And is not linked on the guide. So most users likely dont use it.
A bit late, but it's actually the other way around: NTFS has journalling, which prevents metadata corruption if the drive is disconnected while writing to the file system. FAT32 does not.
This won't prevent corruption of the actual data, but it should keep the file system intact.
- Joined
- May 2, 2016
- Messages
- 449
- Trophies
- 0
- Location
- the deepest depths of hell.
- Website
- crimson.ninja
- XP
- 1,510
- Country
Hmm.. I heard it was the other way around.. Should have looked into it more. Thanks for telling me!
- Joined
- May 2, 2016
- Messages
- 449
- Trophies
- 0
- Location
- the deepest depths of hell.
- Website
- crimson.ninja
- XP
- 1,510
- Country
Im not saying it doesn't work. I'm just saying the average a9lh user probably doesn't use it. and instead uses the precompiled binarys. In fact i'm using it on my new 3ds, just in case. But yeah this issue is counteracted by Shadownand or the nightly.
D
Deleted User
Guest
- Joined
- Oct 22, 2008
- Messages
- 1,942
- Trophies
- 0
- Age
- 39
- Location
- I'm so high, I don't even know!
- XP
- 1,229
- Country
Add to the list if you perform a system format on a N3DS while on 2.1 you will brick.I made this post for pure informative purposes. My goal here is not to scare someone which is new in all of this CFW stuff, but for people to evaluate possible risks to see if it is worth to do what they want to do (like migrating from MenuHax to A9LH).
There's certain considerations to take into account, but i will make a little summary of all that:
1.- double-check the requirements and steps of the tutorials.
2.- Always have a NAND backup with you.
3.- Always follow the tutorials step by step exactly as written. Don't skip anything on the subject.
If your console receives several hits, his vital components will have several damages, and obviously resulting into a brick.
Let's suppose that you want to update/downgrade your sysNAND using SysUpdater. If your console is for example "EUR" and you install an "USA" cia pack, you will brick your console.
If you have a N3DS and you use files that meant to be used on O3DS (mainly update/downgrade stuff or NAND restore), you will brick your console.
Every process involving modification on sysNAND is *Extremely* delicated, so if you're doing something like a sysNAND downgrade or modifying some NAND titles and your console shuts down or interrupts the process somehow, your system will brick.
Sometimes you met all the requirements and needed care to do whatever you're going to do (IE: Arm9LoaderHax tutorial). But all these process not only relies on files or steps, but also of the quality of the tools you're using. So, if you're using a chinese SD copy or a bad quality SD card, it may appear some unexcepted error on the middle of a delicated process, resulting into a irremediable damage to your console.
This is self-explanatory. If your emuNAND is bricked, cloning it into sysNAND will have the same result.
Same as above. If your NAND backup is broken/corrupted somehow, and you use it to reflash the sysNAND, your console will brick for sure.
If your emuNAND has a modified Secure_info (mainly to elude the ban of the console or archaic region change method) and you clone it to sysNAND, or if you try to inject a modified Secure_info to sysNAND, it will be insta-brick. Can be fixed via Hardmod, but if you ended up without backups, your console will be bricked for life.
If you're doing a NAND injection (or whatever thing you're writing on the NAND) and the app you're using shows an error or a failiure message, don't reboot. If you have common sense, you will notice that on reboot, the 3DS will try to boot the OS. But since the injection has failed/corrupted somehow, it obviously won't boot because the system is corrupted. If you have A9LH then is not a problem, unless you're using programs that don't protect the firmo/firm1 partitions like Decrypt9. On those cases you will not only archieve a brick, but you will aslo loose the A9LH.
Back on 2014, a lot of 3DS got bricked thanks to an Gateway firmware (primary the 2.0b2 one) while checking configuration on emuNAND. What it does is that on some parts in the system settings menu, the sysNAND was being readed an writted even if isn't supposed to (The NAND redirection wasn't working on those scenarios on purpose). And given that insta-write on the sysNAND, the system will not recognize the NAND on the next reboot, and so, the result is the famous *BSOD*.
So, if you have a 3DS flashcart and is outdated: UPDATE IT. Also, the same thing can be archieved by using the emuNAND for what should not be used to, like configuring the whole 3DS system, or using Normmatt's region free patch
Let's suppose that you have an untouched 3DS with an old firmware ver. (like 9.x or less). And given the fact that is old, you may think to use old well-known tutorials to get into CFW, right? Well, no. A lot of things has changed on little time and most of the process have been optimized. So if you're going to use old tools from old tutorials, you're risking yourself to archieve a brick.
This is self-explanatory. If you don't have any knowledge on basic solding for Hardmod, don't insist, you'll be liked to break the entire console if you don't know what you're doing. The same thing can be archieved if you fail to restore your sysNAND if you got some short circuit, or your PC shuts down, or you format the NAND memory, or you go crazy and rip the NAND memory chip off the motherboard. The only solution for this is to buy another 3DS.
If you somehow managed to send weird or bad patterns to the LED via i2c, you will brick the i2c flash commands and thus, bricking the MCU an being unable to boot the system. This brick isn't recoverable even with Hardmod, so the only solution for this is to buy another console.
This is a softbrick since the sysNAND still works. If your 2DS is on a version below 6.x (mostly 4.x given the MSET exploit) and format your 2DS sysNAND on system settings, on reboot wil ask you to turn on the 3D, but since 2DS doesn't have that feature, you'll be stuck there. It is possible to get out of that inferno somehow with Recovery Mode.
*A9LH RELATED*
As explained on the Arm9LoaderHax tutorials, every OTP is unique per console. So, using OTP's of another console, even if both consoles are virtually the same, for example, O3DS black "USA" CTR-001, you will screw up everything. The reason this bricks is because a hash of the OTP is used as the encryption key for ARM9Loader, so using the wrong OTP results in the wrong key. It can be fixed using a hardmod, assuming you have a working sysNAND backup.
If you have A9LH already installed, you will notice that there's two files that are inyected on the NAND: Stage 1 and 2. If you try to update one without the other, your system will brick. And since the A9LH wasn't updated properly, the Payloads won't work. You can solve it via Hardmod if you have a NAND dump with the A9LH installed.
Since there's no New console that officially supports versions lower than 4.x, updating via System Setting after the 2.1 downgrade will brick your console for sure. Why this bricks is because you're running a Old3DS-exclusive version, and if you try to update, you will download the Old3DS version data, not the New3DS ones.
After a heart attack to see if the downgrade to 2.1 was succesfull or not, you may think to have a good rest to continue another day, right? Well, that's a bad idea. There's a lot of reports that explain that leaving the new3DS on Sleep Mode will brick the console. So do the A9LH installation without delay!
As adviced on the github site, using dgTool with arm9loaderhax already installed is a very dumb move. For inexperienced users, dgTool is a required tool to downgrade the 3DS's NATIVE_FIRM to be possible to downgrade the system to 9.2. What it does is perform a write on firm0, which is a partition of the NAND where NATIVE_FIRM is located. However, since arm9loaderhax perform a write on firm0/firm1, using dgTool will "disable" arm9loaderhax, and therefore, your system won't boot becuase firm0 has garbage on it. Be smart and don't use it when is not needed.
After you have succesfully installed Arm9LoaderHax, you can finally relax and be happy to know that you won't see the Yellow-screen freeze of MenuHax, or you won't fear a NAND brick anymore. But of course, don't relax that much. Keep in mind that the Arm9Loader will work if you have the neccesary files on the SD (implying that you're not using the mini-CFW fork), so if you're messing up with the SD reader slot of the console (like pushing the SD card with brute force), the Arm9 will not do anything if it can't read the SD. The solution for this is to hardmod, but you won't be able to go into CFW again unless you buy a new console or fix the SD slot
And so with this list, am i losing something?
@Plailect, maybe you can add that as a warning on the guide?
Plailect has enough disclaimers, people just choose not to read them. It's not going help, even in bold face pt 42 and bright red. The guide is as noob friendly as it can get. Perhaps if someone wanted, they could make an "idiot proof" version, that has a page timer like one of those online college exams. You know where they HAVE to sit on one page for like 30 seconds or so, before being able to hit next. Maybe then they would read all the info and make sure that each step is done correctly before moving forward. 10/10 people that brick with that guide are lazy, in a rush or cocky.
Bricked using this method by slamming the taxi door shut with the coat hanging out and the console in the coat pocket. Top screen smashed. Console refused to boot beyond blackscreen. Bootloader menu still displayed but only on bottom screen. Bought another used console. Spent 1.5 days disassembling both then reassembling with replaced console screen. Unbrick was eventually successful.
ribboncablesfromhell
- Joined
- Oct 22, 2008
- Messages
- 1,942
- Trophies
- 0
- Age
- 39
- Location
- I'm so high, I don't even know!
- XP
- 1,229
- Country
Which is very admirable, but we can only do so much save from doing it for them.
- Joined
- Oct 22, 2008
- Messages
- 1,942
- Trophies
- 0
- Age
- 39
- Location
- I'm so high, I don't even know!
- XP
- 1,229
- Country
OK. I just can't see how adding a red bubble with one sentence telling people another way they can brick their device is doing too much. Sounds like the opposite to me. Anyway, it was merely a suggestion. If Plailect wants to add it, good. If not, I tried.
It's already in the guide... "Never format a 2DS while on a version <6.0.0 or you will be unable to complete initial setup and will BRICK!" Taken directly from the guide in the 2.1 ctrnand transfer section. The same warning on the front page isn't going to help.
- Joined
- Oct 22, 2008
- Messages
- 1,942
- Trophies
- 0
- Age
- 39
- Location
- I'm so high, I don't even know!
- XP
- 1,229
- Country
- Joined
- Oct 22, 2008
- Messages
- 1,942
- Trophies
- 0
- Age
- 39
- Location
- I'm so high, I don't even know!
- XP
- 1,229
- Country
That's about updating the system. Trust me, I looked through the guide. There's no mention of a system format bricking a N3DS on 2.1.
From my personal expierence just today, I hit my console because I was playing Tomodachi Life and it bricked for about a minute then it ran as normal again *no savedata lost*
Similar threads
