[Captivate Android Development] brunson:
LOL!

I had a few problems after flashing (I'm still on 2.2beta9.1.3, FWIW). The first was definitely my fault, I restored system data back after the upgrade using TiBU, so I reflashed with a CWM data wipe.

After the second flash I had two FC issues, the first was the Email app would crash when I opened a compose window (fixed by deleting data and reconfiguring) and the second was with Chrome2phone, but that just mysteriously started working after I ignored it for several days.

Looking at the update script, it starts with:

format SYSTEM:
format CACHE:
format DATADATA:
format DATA:

delete SDCARD:update.zip
delete_recursive SDCARD:Android

copy_dir PACKAGE:system SYSTEM:
copy_dir PACKAGE:updates TMP:/updates
copy_dir PACKAGE:sdcard SDCARD:

So, from the outset system, cache, data and datadata are formatted. Nothing in any of those filesystems should have anything to do with problems after flashing. System is restored from what's in the ROM release, updates are firmware code, they're just tucked away for later use, and sdcard from the ROM is copied over to SDCARD:, but SDCARD was not formatted, so what was released with the ROM is comingled with what you had in your /sdcard before flashing.

The rest of the script is simply:

Installing su

setting up toolbox symlinks

setting some permissions

installing busybox

applying firmware upgrades using redbend_ua

So, the only remnants of your old system are on your sdcard, which means primarily system and application data.

Taking a look at the mounted filesystems (after filtering out application loopback mounts with grep):

echo(~)$ ~/android-sdk-linux_86/tools/adb shell mount | grep -v dm-.
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sys /sys sysfs rw,relatime 0 0
/dev/block/mmcblk0p2 /data ext4 rw,noatime,barrier=0,data=ordered,noauto_da_alloc 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
/dev/block/stl6 /mnt/.lfs j4fs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/stl9 /system rfs rw,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl10 /dbdata rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl11 /cache rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/stl3 /efs rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:9 /mnt/sdcard/external_sd vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:9 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/external_sd/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

rootfs, proc, sysfs, tmpfs, devpts and anything that is mounted from 'none' is a kernel or ram based filesystem and not persistent across boots. /data is an ext4 filesystem, that's part of a lagfix, we know system, data and cache were formatted. I'm going to make a leap and decide that dbdata is datadata, which was formatted, external_sd is obvious.

A bit of googling reveals j4fs to be a moviNAND filesystem. /efs seems to contain stuff for the GSM radio and /mnt/secure/asec appears to be intertwined with the application specific device mapper mounts that we excluded from the get go.

That leaves external_sd, which we know isn't involved, and /sdcard, which must be the culprit.

Edit: I think this has become obligatory - http://www.youtube.com/watch?v=dFUlAQZB9Ng