Hacking LINUX: how to move SD content and emunand partition to BIGGER card

[romanaOne]

There's no emunandtool, so I have to use dd, a utility I am tempted to call "Disk Destroyer."

I tried to move my emunand partition and games from a 16GB SD to a 32GB SD using dd and I think I messed up the partition table.

Everything seems fine on the 3DS, but I can't write to the card on my PC. I keep getting strange errors in syslog when I insert the card:

[  25.074350] mmc0: cannot verify signal voltage switch
[  25.184338] mmc0: new ultra high speed SDR50 SDHC card at address aaaa
[  25.199483] mmcblk0: mmc0:aaaa SS32G 29.7 GiB

and all sorts of weird stuff about trying to write beyond the end of the device when I try to copy files to the card. It then goes read-only. (I'm not going to attempt it again, so I can't post the specific error messages.)


Here is what I did:
1. Back up emunand from old 16GB SD card:

dd if=/dev/mmcblk0 of=dummy.bin count=1
dd if=/dev/mmcblk0 of=emunand.bin count=1 skip=1953792
dd if=/dev/mmcblk0 of=emunand.bin count=1953791 skip=1 seek=1

2. Copy all SD content, just dragged and dropped the Nintendo folder onto my desktop.

3. Formatted/paritioned the NEW 32GB card for emunand using the gateway menu.

4. Restored my old emunand backup to the emunand partition to the card:

dd if=dummy.bin of=sd_tmp.bin count=1
dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 bs=8M
rm sd_tmp.bin

5. Copied Nintendo folder SAVs, and various other 3DS cruft onto the remaining 30.8 GB partition.

I think I must have screwed something up because the filemanager says I have a 30.8GB partition but the Ubuntu Disks partitioner/editor utility says something else! See screenshots.

I am not sure how to use dd to properly fix the partition table. I'm pretty sure I messed it up with the restore in step 4.

fdisk agrees with Disks: the partition table from my old card ended up on the new card!

Welcome to fdisk (util-linux 2.25.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1      2097152 31213567 29116416 13.9G  c W95 FAT32 (LBA)

I suppose I should actually look at the stuff I copy and paste into shell scripts out of these forums:

dd if=dummy.bin of=sd_tmp.bin count=1

When restoring to a LARGER SD card, you do not want to copy the old dummy.bin!

SOLVED. DOH!

 

[bender42]

4. Restored my old emunand backup to the emunand partition to the card:

dd if=dummy.bin of=sd_tmp.bin count=1
dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 bs=8M
rm sd_tmp.bin

The first dd command you're running here overwrites the MBR (essentially the partition table) of your new 32GB SD card with the backed up MBR from your old 16GB SD card. Since you've already partitioned your new SD card in step 3, you don't need to do anything else to your partition table. To restore your emunand, you only need to run

dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953791 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 seek=1 bs=8M
rm sd_tmp.bin

The first command would be useful if you had backed up your 16GB card previously, somehow managed to corrupt your partition table, and wanted to restore from a backup; but since you're looking to move to a new SD card entirely, you don't need to worry about the old MBR/partition table.

 

[romanaOne]

The first dd command you're running here overwrites the MBR (essentially the partition table) of your new 32GB SD card with the backed up MBR from your old 16GB SD card. Since you've already partitioned your new SD card in step 3, you don't need to do anything else to your partition table. To restore your emunand, you only need to run

dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 bs=8M
rm sd_tmp.bin

The first command would be useful if you had backed up your 16GB card previously, somehow managed to corrupt your partition table, and wanted to restore from a backup; but since you're looking to move to a new SD card entirely, you don't need to worry about the old MBR/partition table.

This didn't work. In fact, the code block above will corrupt the SD card by wiping the SD partition table entirely. Then the card will not work in the 3DS and a (windows) PC will prompt to format it when you insert it.
(Linux will of course do absolutely nothing when you insert it.)

After using gateway to repartition the card for emunand, I backed up the first block(?) of the new card to dummy.bin and then used the original restore script above. I think it is less confusing this way.

sudo dd if=/dev/mmcblk0 of=dummy.bin count=1

Strangely, I lost all my folders after this, but the CIAs and game saves are fine. I guess I did not have sys- and emu- nands truly unlinked after all, since the 3DS must have stored the information about the old card internally.

I'd done a system format from emunand when I first downgraded and installed emunand to my old 16GB card. I notice the Gateway manual says to unlink by formatting sysnand with no SD card or cartridges inserted.

I also wonder about the "cannot verify signal voltage switch" error in the system log when I use this card. I tried several other SD cards and this message does not appear. The card is a SDHC 4 32GB Sandisk.

Just for fun, I took a look at dummy.bin in a hex editor. What the hell? (See attachment picture.)

 

[bender42]

This didn't work. In fact, the code block above will corrupt the SD card by wiping the SD partition table entirely. Then the card will not work in the 3DS and a (windows) PC will prompt to format it when you insert it.
(Linux will of course do absolutely nothing when you insert it.)

Oops, I forgot to adjust the dd commands to account for the missing MBR block. "seek=n" seeks n 512 byte blocks into the outfile before writing (or in the case of "bs=8M", it would seek n * 8MB blocks). The "bs=8M" option can make writing to the SD card happen faster, but it means we can't use seek to only skip over the first 512 bytes of the SD card. We would either need to exclude "bs=8M":

dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953791 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 seek=1 bs=8M
rm sd_tmp.bin

OR we could populate the first 512 bytes of sd_tmp.bin with the MBR of the new SD card:

dd if=/dev/mmcblk0 of=sd_tmp.bin count=1
dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 bs=8M
rm sd_tmp.bin

 

[romanaOne]

Oops, I forgot to adjust the dd commands to account for the missing MBR block. The "bs=8M" option makes the write happen faster, but it means we can't use seek to skip only 512 bytes. We would either need to exclude "bs=8M":

dd if=emunand.bin of=sd_tmp.bin skip=1 [S]seek=1[/S]
dd if=emunand.bin of=sd_tmp.bin count=1 [B]seek=1953791[/B] [S]seek=1953792[/S]
dd if=sd_tmp.bin of=/dev/mmcblk0 [B]seek=1[/B] [S]bs=8M[/S]
rm sd_tmp.bin

OR we could populate the first 512 bytes of sd_tmp.bin with the MBR of the new SD card:

dd if=[B]/dev/mmcblk0[/B] of=sd_tmp.bin count=1
dd if=emunand.bin of=sd_tmp.bin skip=1 seek=1
dd if=emunand.bin of=sd_tmp.bin count=1 seek=1953792
dd if=sd_tmp.bin of=/dev/mmcblk0 bs=8M
rm sd_tmp.bin

BOLD never works in a [thingy] bold stuff [/thingy] block.

Oops, I forgot to adjust the dd commands to account for the missing MBR block.

Yeah, I kind of noticed that, LOL. Ye gods, I have hated partitions since the days of DOS 5 and it keeps coming back.
Seems like only yesterday you could throw a system folder on a disk and make it bootable.

I hope supercard plus is not vapor tech, but I have a bad feeling gateway is going to be as good as it gets in 3DS flashcarts.

You ever notice how flahscarts always die, with rumors swirling just before some great huge release that never comes?

Err, getting a little frustrated. Time to chill and play some Animal Xing.