[Verizon Samsung Galaxy S III] Nicene Nerd:
Tips for Better Dual Booting

If you can, use a class 10 SD card. Lower clases (esp. class 4) tend to host laggy external ROMs.

If you plan on dual booting an AOSP and a TouchWiz ROM, consider putting the TouchWiz ROM on internal storage regardles of which one you want to use as your daily driver. Since TouchWiz ROMs are generally bulkier and slower than AOSP ROMs, they will benefit from the speed of NAND memory, while the speed of the SD card will not adversly affect an AOSP ROM as much.

Make a recovery backup of your boot partition both before and after flashing an external ROM. This will enable you to switch back and forth between ROMs even if you can't use MaulBoot for some reason (e.g. you lose root on one or both ROMs).

If you are, as I am, flashed to another carrier, be aware that sometimes your service will work differently on your internal ROM than you external. Sometimes one will get service or data while the other does not.

If you want to flash a custom kernel to your external ROM, check to see if it has a boot.img in the update ZIP. If so, the ROM patch button should work on it. If not, the Google Apps patch should work.

Instructions on Patching ROMs for External Use Manually

Using a program like 7-Zip, extract boot.img and META-INF\com\google\android\updater-script from your ROM.

WINDOWS ONLY: Extract the /system/media/audio directory tree. Then delete it within the ROM package, and finally place the extracted audio folder back in /system/media/

Unpack the boot image and its ramdisk. A search of XDA will show you how to do this.

Open the files fstab.qcom and init.target.rc from the ramdisk.

Fix the mount instructions for /system, /data, and /cache. Use the chart below to help.

Find Replace With
----------------------------------------------------------------------------
/dev/block/platform/msm_sdcc.1/by-name/system /dev/block/mmcblk1p2
/dev/block/mmcblk0p14 /dev/block/mmcblk1p2

/dev/block/platform/msm_sdcc.1/by-name/userdata /dev/block/mmcblk1p4
/dev/block/mmcblk0p37 /dev/block/mmcblk1p4

/dev/block/platform/msm_sdcc.1/by-name/cache /dev/block/mmcblk1p3

Repack the boot image.

Open the updater-script and replace the same things you replaced in the ramdisk.

Using 7-Zip or a similar program, update boot.img and updater-script in the ROM zip.

Volia! Your ROM is now ready to use on your external partitions.

Instructions on Patching Google Apps ZIPs

Open the Google Apps package in 7-Zip or a similar program.

Extract the updater-script from META-INF\com\google\android\updater-script

Replace the following:

Find Replace With
----------------------------------------------------------------------------------------------------------------
run_program("/sbin/busybox", "mount", "/system"); mount("ext4", "EMMC", "/dev/block/mmcblk1p2", "/system");
run_program("/sbin/busybox", "umount", "/system"); unmount("/system");

Replace the old updater-script in the ROM zip with the new one.

Volia! You can now flash this Google Apps package over an external ROM.

Explaining the /system/media/audio Step

If you use my MaulBoot ROM Patcher script, you will early on have to perform a step in which you extract /system/media/audio, delete it from the archive, and then place the extracted files back in the archive. Why? See, Linux filenames are case-sensitive. This means, in Linux, ANDROMEDA.ogg is different than Andromeda.ogg. However, Windows filenames are not case-sensitive. In Windows, ANDROMEA.ogg and Andromea.ogg refer to the same file. Unfortunately, since most ROMs are packed in Linux (and since Android is Linux-based), sometimes files just like ANDROMEDA.ogg and Andromeda.ogg will appear in /system/media/audio. When this happens, Windows programs (7-Zip, for example) cannot edit the ROM zip properly. When extracting, though, one of the two files sharing a name will overwrite the other, leaving no duplicates. Thus when they are injected back into the ROM zip, there are no more errors.