Create new partition on Kindle Touch

This is mostly based on the Repartitioning Kindle Filesystem thread on Mobileread, closely following eureka instructions (at least, in theory). Thanks!

eureka main idea is described at post.

Below, list the commands/steps that I have used on my kt2. This is not a how-to.

First, a backup of the files on the kindle userstore partition. This is the partition that is normally seen when the kindle is connected via usb to a computer. The new partition will be created from this userstore partition. (The files on userstore partition will have to be restored from the backup) Note: do not use wifi, for the kindle can auto-upgrade!

Pre-requisite: Kindle fw 5.6.5 jailbreak

Ssh into kindle:

unmount userstore parition:

/etc/upstart/userstore stop

create 2 partitions in /dev/mmcblk0p4 , (originally it contains only the userstore partition) The sfdisk option -uS means the unit is Sectors.

sfdisk -q --force -uS /dev/mmcblk0p4 <<EOI

From the sfdisk man page,

sfdisk reads lines of the form
\<start> \<size> \<id> \<bootable> ..
where each line fills one partition descriptor.

Here, I retain the original start sector 16, id of b , used for the userstore partition; and set the userstore partition size to be 3198944 sectors.

And the new Linux partition start sector is 3198976, and the remaining size is used for the new partition. (default id means Linux partition) There is an unused gap of 16 sectors between the first and new partitions. (3198976 - (16 + 3198944) = 16) There is no reason for this unused gap. (except maybe for the sake it mirrors the userstore start sector of 16)

remove mntus.params and remount userstore partition:

rm /var/local/system/mntus.params
/etc/upstart/userstore start

The userstore start script will auto-generate the mntus.params file if it does not exist.

mount and format the new partition with block-size of 1024:

losetup -o 1637875712 /dev/loop/8 /dev/mmcblk0p4
mkfs.ext3 -b 1024 /dev/loop/8
losetup -d /dev/loop/8

The relative offset in bytes used in losetup = 3198976 * 512 = 1637875712

Note: eureka thinks ext3 filesystem should be aligned on 4MB (4194304 = 4 * 1024 * 1024) and have block of 1024 bytes. (I dun have much idea about hardware)

Offset of /dev/mmcblk0p4 (in sectors) is in /sys/class/block/mmcblk0p4/start ( mine = 1249280)
Relative offset of new partition to /dev/mmcblk0p4 is 3198976 .
Absolute offset of new partition in bytes = (1249280 + 3198976) * 512 = 2277507072
and 2277507072L/4194304.0 = 543.0 , so my new Linux filesystem is aligned on 4MB. Actually, the new Linux partition start sector of 3198976 is pre-calculated to align on 4MB.

In my case, the 2 partitions are almost equivalent in size, with the new userstore partition slightly larger than the new Linux partition.

mount the new partition on a path:

mntroot rw
cd /mnt
mkdir deb
chmod 755 deb
losetup -o 1637875712 /dev/loop/8 /dev/mmcblk0p4
mount -t ext3 /dev/loop/8 /mnt/deb

If the kindle is rebooted, the new partition will not be mounted automatically. To do so, we need to create an upstart script.

create file /etc/upstart/deb.conf to auto-mount the partition onboot:

    start on started filesystems
stop on stopping filesystems
pre-start script
source /etc/upstart/functions
PART_START=`sfdisk --force -l -uS /dev/mmcblk0p4 | grep /dev/mmcblk0p4p2 | awk /mmcblk0p4/\ '{ print $2 }'`
PART_OFFSET=`expr ${PART_START} \* 512`
losetup -o ${PART_OFFSET} /dev/loop/8 /dev/mmcblk0p4
mount -t ext3 /dev/loop/8 /mnt/deb
f_log I deb mount "deb is mounted"
if [ -e /mnt/deb/var/lib/dpkg ]; then
ln -s /mnt/deb/var/lib/dpkg /var/lib/dpkg
if [ -e /mnt/deb/root/.config ]; then
ln -s /mnt/deb/root/.config /var/tmp/root/.config
end script
post-stop script
source /etc/upstart/functions
umount /mnt/deb
losetup -d /dev/loop/8
f_log I deb umount "deb is unmounted"
end script

In the deb.conf script, the relative offset used by losetup is computed into PART_OFFSET variable, instead of using the hardcoded number. Note: after a kindle upgrade, this file /etc/upstart/deb.conf will be gone, and will need a manual restore.

The extra script after mount, is to auto-link some paths into the new partition, if those paths exist. Those are added subsequently.

At this point, I have forgotten something. I have only come to realize it later, after I check that the reported userstore disk space seems to remain the same as before instead of being about half the original size.

I have forgotten to re-format the userstore partition filesystem.

This is the script to re-format the userstore partition (extracted from userstore script), saved or copied it as ~/vfat and make it executable,

. /etc/sysconfig/mntus
. /var/local/system/mntus.params
MNTUS_PART_START_SECTOR=`cat /sys/class/block/mmcblk0p4/start`
mntus umount

The auto-generated mntus.params file will include MNTUS_PART_SIZE , the userstore new partition size, so after running the script, the reported userstore disk space should be now correct (eg. use df to check).

/etc/upstart/userstore stop
/etc/upstart/userstore start

Except for a kindle system userstore partition re-creation, the new Linux partition is now safe to use. At last, the backup files can be copied back to the new userstore partition.


blog comments powered by Disqus