[Samsung Galaxy Nexus] osm0sis:
I modified my dump using the values from yours and the MD5 matches yours, so I think the latest PIT Magic seems to write the userdata value correctly; the issue I had was that I didn't change cache's block size since I didn't understand that was a sum of the previous partition's values yet. Thanks! :good:

Hmm, I also see that your PITs use the odd-one-out value for userdata count (=15222 MB), from the -0915 "Stock PIT" file. Any idea where that comes from? I'm still waiting on some non-VYL00M chip devices, but no maguro we've checked so far has that, and come with the slightly lower number I reported instead. :confused:

Good news is your PIT, and only stealing from cache, seems to work perfectly. dexopting seems to take the same amount of time and everything. :D

With a universal solution still in mind, leaving userdata untouched for the various device variants and only adjusting system and cache, this afternoon I've whipped up the following:

/tmp/pitfix.sh:

#!/sbin/sh
# PIT Updater for Galaxy Nexus
# osm0sis @ xda-developers
#
# Alters cache to the preset length in MB, adding the difference to system

# new cache block count (length) in MB
cacheMB=128;

# block device containing the PIT
block=/dev/block/mmcblk0;

# offset of the PIT in the block device, and partition size offsets within the PIT; count offsets are size offset + 4
pit=17408;
sysOffset=1500;
cacheOffset=1632;
dataOffset=1764;

# functions for dumping then converting the little endian hexadecimal into decimal for calculations and converting then writing back
dump_hex2dec() { echo "$(printf '%d\n' 0x$(dd ibs=1 count=4 skip=$(($1+pit)) obs=1 if=$block 2>/dev/null | od -hv | head -n 1 | awk '{ print $3$2 }'))"; }
write_dec2hex() { echo -ne "$(printf '%08x\n' $2 | sed 's/.\{2\}/& /g' | awk '{ print "\\x"$4"\\x"$3"\\x"$2"\\x"$1 }')" | dd obs=1 count=4 seek=$(($1+pit)) of=$block; }

# create a backup of the existing, untouched PIT with a timestamped filename
dd if=$block of=/sdcard/backup-$(date +%Y-%m-%d.%H%M%S).pit bs=1 count=4096 skip=$pit;

# check the PIT against known values for userdata to ensure it is an original PIT for the device
dataSize=`dump_hex2dec $dataOffset`;
dataCount=`dump_hex2dec $((dataOffset+4))`;
if [ "$dataSize" != 2379776 ]; then
echo "Non-standard userdata size (start offset) detected... aborting."; exit 1;
fi;
case $dataCount in
28397534|59944926) ;;
*) echo "Non-standard userdata count (length) detected... aborting."; exit 1;;
esac;

# calculate new block counts (lengths) for cache and system; 1 MB is 2048 blocks
sysCount=`dump_hex2dec $((sysOffset+4))`;
cacheCount=`dump_hex2dec $((cacheOffset+4))`;
cacheCountNew=$((cacheMB*2048));
sysCountNew=$((sysCount+cacheCount-cacheCountNew));

# calculate new block size (start offset) for cache; the sum of the previous partition (system)'s block size and block count
sysSize=`dump_hex2dec $sysOffset`;
cacheSizeNew=$((sysSize+sysCountNew));

# abort if cache has already been altered
if [ "$cacheCount" == "$cacheCountNew" ]; then
echo "cache count (length) already matches target amount... aborting."; exit 1;
fi;

# write back the updated values to the PIT in the block device
write_dec2hex $cacheOffset $cacheSizeNew;
write_dec2hex $((cacheOffset+4)) $cacheCountNew;
write_dec2hex $((sysOffset+4)) $sysCountNew;

# zero minor gpt/efs areas of the PIT to mimic external editing and flashing
for i in 200 596 632; do
echo -ne "\x00\x00\x00" | dd obs=1 count=3 seek=$((i+pit)) of=$block;
done;

# format the altered partitions to their new lengths; userdata remains untouched
#make_ext4fs /system;
#make_ext4fs /cache;

# repair and resize all partitions as a final measure to ensure data integrity
#e2fsck /system;
#resize2fs /system;
#e2fsck /cache;
#resize2fs /cache;
#e2fsck /data;
#resize2fs /data;

echo "Success!";
exit 0;

This is pretty much the sum of all our knowledge thus far. I'm still working out the format commands so they're commented out, but otherwise it should work, though I'd caution against trying it just yet. It needs to be run from recovery, but I haven't decided what I want the delivery method to be (as a shell script update-binary, run by another shell script update-binary, or run by an EDIFY updater-script), beyond a flashable zip. Thoughts? Comments? Fixes? :cowboy::cool:

Edit

: Fixed the dump_hex2dec function to work in recovery. I also noticed in my function testing that even though the 15222 MB userdata block count value was passed to Odin using [MENTION=4263181]mn.code[/MENTION]'s -osm0sisV2 PIT above, the value actually written (verified by dump) was the correct, lower one. I'm guessing Odin knows best so I've removed the higher one as an accepted value from the script. :good:

Edit 2

: I've now thoroughly tested it by running it manually in recovery after adb pushing it to /tmp but I've run into a problem with recovery not acknowledging the new sizing in make_ext4fs, or resize2fs. I have dumped the adjusted PIT and it looks flawless, all the values were written correctly and nothing else was touched (verified in a hex editor). fastboot formats the partitions to the correct new sizes, but then recovery acts like they're corrupt, showing them as 0 until you format, at which point they go back to being their old sizes. :confused:

Edit 3

: Odin flashing the dump of my adjusted PIT and then fastboot formatting resulted in recovery recognizing everything properly again. So there must be some voodoo we're not aware of that Odin does after flashing the PIT. Any ideas?

If all else fails, I guess I can just make a flashable zip to dump the original PIT as a backup, copy the backup file, adjust the values in the file only, then instruct a user to Odin flash their personalized PIT, but that's not nearly as fun or useful. :(

Edit 4

: Add zeroing of minor gpt/efs areas as per this post. Still not registering in recovery though, as above.