And the "userstore" script contains this code snippet (with env vars resolved):
PHP Code:
# try to read back the existing partition size
PART_SIZE=`sfdisk --force -l /dev/mmcblk0p4 | awk '$1 ~ '/p1/\ '{ print $5 }'`
if [ -z "${PART_SIZE}" ]; then
_CREATE=1
fi
if [ ${_CREATE} -ne 0 ]; then
# clear the first cylinder
dd if=/dev/zero of=${MNTUS_DEV} bs=${_CYLSIZE} count=1
# create the volume partition
sfdisk -q --force -uS ${MNTUS_DEV} <<EOI
${PART_START},,b
EOI
# read back the created partition size
PART_SIZE=`sfdisk --force -l ${MNTUS_DEV} | awk '$1 ~ '/${_BASE_MNTUS_DEV}p1/\ '{ print $5 }'`
Notice that this script (used to blast and rebuild the /mnt/us userstore) lists the partition structure INSIDE /dev/mmcblk0p4, and then extracts size information from "p1" (i.e. mmcblk0p4p1), where the actual loop-mountable partition resides.
It might be a little more obvious what is going on here if they had created device nodes for the extended partitions, instead of loop mounting with offsets (though it helps that the offsets and sizes are calculated using partition information returned by sfdisk). It should be "relatively" easy to shrink mmcblk0p4p1 and add mmcblk0p4p2. And with a little luck, USB-exporting mmcblk0p4 would also
automagically export its internal extended partitions (even though windows may choose to ignore all but the first). A sane OS like linux should see all the partitions defined in the extended partition table shared over USB.
EDIT: I have been reading lots of kindle system (and installer update) scripts, trying to eduficate myself on this subject. This topic seemed appropriate to post these little notes to myself (and anybody else who may benefit from them).