I had these instructions lying around in a text file on my computer for months now and I'd just like to share it with you guys 
Note: I'm afraid this is a bit too complex for some users, more advanced users are best suited for this.
This is a procedure that I had created for getting rid of the dreaded update nag in EmuNAND through constant reviewing of 3dbrew and trial and error. (I still don't fully understand why it works, so some steps could be unnecessary or could potentially hold implications. Use at your own risk!) From what I understand, the import.db is a database file that stores a list of titles that are about to be installed (such as pre-downloaded updates). This is done so the entires from import.db can easily be copied over to the title.db. I noticed when the 3DS auto-downloads an update it will grab all the update data and store them as titles in the NAND, but not actually install them. It will then write to the import.db, adding in entires for the update. With this proof of concept, by replacing the import.db with an old one from before the update nag and removing all the titles the 3DS downloaded for the update it will think there isn't an update to install, thus removing the nag. I have preformed this procedure on my N3DS 9.5 EmuNAND to remove the nag months ago and still suffer no issues to this day.
What's needed:
Cleaning up:
This probably isn't absolutely necessary as the 3DS no longer recognizes there to be anything to install/nag about now that we have the import.db replaced, but there are still a bunch of files the 3DS had downloaded and stored for the now aborted auto-update. To clean up the mess made, go into the /titles folder and search for files that were modified/created on a date closest to the time you began getting update nags and deleting them. (This is pretty easy on a Mac, I am unsure about Windows/various Linux distros)
Finishing up:
Confirm the 3DS no longer sees the pre-downloaded update data by taping on "System Update" in System Settings. It should prompt you to connect to the internet to update, rather than saying the update can be preformed without an internet connection.
I haven't seen any implications from doing this import.db swap so far. Perhaps the age of the old import.db has something to do with it. Again, this is at your own risk. If there ever is a problem, feel free to restore an EmuNAND backup. There should be no bricks resulting from this as it is only modifying EmuNAND.
Hope you guys were able to follow this, as these were originally intended to be for my own internal use. I have many more of these little procedures I've created to make EmuNAND usage just a bit less annoying. Whenever I get the time to polish them up I'll be sure to post it here! If anybody tries this, please publish your results. Given enough research and time, there should be a way to remove the update nag on EmuNAND without the need of an old EmuNAND backup.
Note: I'm afraid this is a bit too complex for some users, more advanced users are best suited for this.
This is a procedure that I had created for getting rid of the dreaded update nag in EmuNAND through constant reviewing of 3dbrew and trial and error. (I still don't fully understand why it works, so some steps could be unnecessary or could potentially hold implications. Use at your own risk!) From what I understand, the import.db is a database file that stores a list of titles that are about to be installed (such as pre-downloaded updates). This is done so the entires from import.db can easily be copied over to the title.db. I noticed when the 3DS auto-downloads an update it will grab all the update data and store them as titles in the NAND, but not actually install them. It will then write to the import.db, adding in entires for the update. With this proof of concept, by replacing the import.db with an old one from before the update nag and removing all the titles the 3DS downloaded for the update it will think there isn't an update to install, thus removing the nag. I have preformed this procedure on my N3DS 9.5 EmuNAND to remove the nag months ago and still suffer no issues to this day.
What's needed:
- An old EmuNAND backup .bin created prior to the update nag showing up (this will be referred to as the "old EmuNAND backup")
- Your current EmuNAND .bin (this will be referred to as the "new EmuNAND backup")
- Xorpads for decrypting the .bin files
Cleaning up:
This probably isn't absolutely necessary as the 3DS no longer recognizes there to be anything to install/nag about now that we have the import.db replaced, but there are still a bunch of files the 3DS had downloaded and stored for the now aborted auto-update. To clean up the mess made, go into the /titles folder and search for files that were modified/created on a date closest to the time you began getting update nags and deleting them. (This is pretty easy on a Mac, I am unsure about Windows/various Linux distros)
Finishing up:
Confirm the 3DS no longer sees the pre-downloaded update data by taping on "System Update" in System Settings. It should prompt you to connect to the internet to update, rather than saying the update can be preformed without an internet connection.
I haven't seen any implications from doing this import.db swap so far. Perhaps the age of the old import.db has something to do with it. Again, this is at your own risk. If there ever is a problem, feel free to restore an EmuNAND backup. There should be no bricks resulting from this as it is only modifying EmuNAND.
Hope you guys were able to follow this, as these were originally intended to be for my own internal use. I have many more of these little procedures I've created to make EmuNAND usage just a bit less annoying. Whenever I get the time to polish them up I'll be sure to post it here! If anybody tries this, please publish your results. Given enough research and time, there should be a way to remove the update nag on EmuNAND without the need of an old EmuNAND backup.
Last edited by Hiatus,
