[Nintendo Switch News, Guides, Discussion , Develop] Count_NOOBula:
Well I appreciate the compliment [MENTION=10069138]Nila-sama[/MENTION], but they call me Count_"NOOB"ula for a reason: I'm far from knowledgeable on Android. (OK fine I call myself that). That doesn't mean we can't put our collective noob heads together & use some basic reasoning to try to brainstorm possible causes for this unique issue. I've tried looking through many threads to see if anyone else has had this problem; wasn't able to find anyone.

I'm sorry for what appears to be a wall of text below, [MENTION=10075817]krampyl[/MENTION]. I'm not a writer & English happens to be my second language. But I tried my best to be concise to respect this thread and your time.

It must suck being in your situation. You've had to spend so much time trying to set up your different SD cards ..only to be disappointed with errors like these. But I promise you'll eventually find some workaround or a simple misstep that lead to errors like this. We all have at some point. You're THIS CLOSE close to enjoying Android on your NX. No one here wants to keep you from enjoying Switchroot, so please be as patient with them as they are to you. If you stick with it, I'm sure you'll be seeing that Android boot logo in no time. Troubleshooting is kinda like checking your algebra equation: all it takes is one wrong +/- to screw up the solution to the equation.

First the good news: Since you couldn't set up Android, obviously you haven't lost any personal data Android app data. I'm sorry for the time you've most trying to get this working on so many different cards but IT COULD'VE BEEN WORSE. Count yourself #blessed.

Second: the fact that HorizonOS correctly formats your card AND Hekate recognizes all the card metadata properly, means it is VERY UNLIKELY that your card is the problem.

The error log makes one thing absolutely clear: this is a system directory MOUNTING problem. In an alternate universe, had you not experienced this issue and created a twrp backup which you later tried to restore, TWRP would have to "mount" the backup files located in /TWRP/backups/name.of.your.backup folder. If that mounting process failed due to a damaged or incomplete backup, it's likely a similar mount error would pop up during restore. I say that cuz the directories mentioned in your error log are the main OS directories backed up by twrp. Your card isnt letting you boot likely cuz it can't find these crucial directories on the nonfat32 partition.

This leads me to believe that there was some problem during the IMG writing phase of your setup. Etcher correctly wrote TWRP to the SD card but likely had issues writing the Lineage system directories. Maybe the IMG you downloaded got damaged/got corrupt/was incompletely downloaded due to some network error. My first advice? Check the 'SHA1 Sums' of the 128GB IMG you're trying to burn with the values on page 1 of the thread. A hash mismatch would indicate a damaged download causing a defect in file integrity. Or maybe Etcher is having some problems on your system/OS My second advice: trying a different computer/OS or download the latest version of Etcher from a different source.

How could etcher properly write TWRP to the card but not write all the Android system files?, you might ask. Because for those new to Android, TWRP is not part of android. It's just s special app, called a recovery tool. TWRP is to Android what Hekate is to our Switch. Like Hekate, TWRP runs OUTSIDE of the main OS i.e, before the OS system files even load.

My rational: if you were installing LineageOS on your phone/tablet, you'd first install twrp on your unlocked device (which installs TWRP on the device's NAND); format your nand in TWRP and then you'd flash the OS zip file in TWRP. Note that phone/tablet this process implies things: if you think of the device's original OS files install as a BOX, then it seems TWRP installs itself outside this box << that's why TWRP is called RECOVERY. How does this apply to your problem? Well, once Etcher finishes, clearly TWRP boots fine from your SD card's non fat32 partition, meaning Etcher perfectly installed TWRP "outside the box" as a recovery tool. However, Etcher clearly had issues setting up the IMG's lineageOS files " inside the box". To prove this ridiculous sounding box theory, do me a favor: at TWRP's home screen, tap Advanced > File Manager. What do you see? Few or no folders? Then I'm probably right & Etcher may have messed up the IMG writing. If the file manager does show an "sdcard" folder then clearly Etcher burned the fat32 partition correctly but messed up burning the other partition likely due to a damaged/corrupt downloaded IMG. Another simple test: on TWRP's home screen, tap Backup. How big is the estimated backup total when you read the numbers next to the two or three directories it's about to backup? Is it ZERO mb? I have a feeling all the folders twrp bsckups will only show as zero MB if Andrioid system files don't exist on your sdcard. If they do, then clearly Etcher didnt burn the Android System directories to the non fat32 partition or may have corrupted them. Please post pix of TWRP's file manager and Backup screen. The normal backup size is typically at least 1 GB after a fresh Lineage install. And normally, the twrp file manager will show you s bunch of different directories.

I'm running a 64gig image on a 64gig Kingston U1 SD card and haven't had any sd related issues (including the "poor performance on u1 cards" a few users have reported). I used "MiniTool Partition Wizard v11.4 Free" to format the card as fat32 on Windows10, then Etcher for the rest. Advice: Try writing a smaller img on a smaller/slower card, maybe a U1 Kingston card which is cheap AF atm. See if you get the same error. If that works, then your downloaded 128 GB IMG may have been interrupted, corrupted or Etcher version/PC may have failed to write all the files to the card. If your problem occurs only in cases where there's a IMG size vs SDcard size mismatch, then I hope [MENTION=576676]langer hans[/MENTION] or some swithroot dev can chime in on solutions for those setting up larger cards. This mismatch problem is unlikely but still possible esp on certain card brands/speeds. That said, I don't know of anyone having this issue if they tried to install a 128GB image on a larger card.

You might be wondering: "well if the IMG burning by etcher was an issue than why didn't Etcher give me an error?" I can't imagine why a 128gb I'm wouldn't work with you 128gb card, but I think regarding you 400gb card, it might have something to do with the fact that you tried burning the 128GB image on a larger card. Etcher may have installed all the system files in the right partition in the right directories but TWRP may be looking in the wrong place on the partition. From what i understand, when IMG file size doesn't match the card size, the extra space on the sdcard is designated as unusable, useless for Android OS. It's possible that TWRP is trying to mount files it can't possibly find from that "unusable" space. Matching IMG size with SD card size will rule out this theory, as twrp would have no choice but to look for system directories in the entirety of the non-fat32 partition. That said, the fact that you also tried a 128GB tells me the problem is likely the Etcher IMG burning process. Maybe the downloaded IMG is corrupt; Etcher is out of date or corrupt or something in your system is interrupting the IMG burning process.

---------- Post added at 12:06 PM ---------- Previous post was at 12:00 PM ----------

[/COLOR [MENTION=10075817]krampyl[/MENTION]: I'd tell you to post this error log in the TWRP xda threads but TWRP dev team currently doesn't support the Switch. Their site has specific twrp imgs for specific devices for a reason. The TWRP build included in this Lineage build is clearly a custom unofficial build << which explains why we have to manually select "internal storage" when selecting where to store a TWRP backup . On a phone/tablet, "internal storage" refers to the phone's NAND but since we're installing android on an SD card, twrp thinks internal storage refers to the non fat32 partition and it thinks "sdcard" is the fat32 2GB partition that shoes up in windows...kinda like a virtual 2GB sdcard inserted in a 62GB tablet (using a 64GB card as an example.

The suggestions and hypotheses above exhaust my knowledge base on this specific error. Others who have successfully burned 128Gzb images or more senior members here at XDA can likely offer helpful, more concrete advice. Good Luck!