Repartitioning Kindle Filesystem

EternalCyclist · 10-30-2012, 02:26 PM

In order to have a separate partition for Debian, I tried to repartition mmcblk0p4.
* umount /mnt/us
* umount /mnt/base-us
* fdisk /dev/mmcblk0p4
** deleting partition 4
** adding new extended partition
** adding new partition for us
** adding new partition for Debian
** writing partition table
Then I wanted to modify /etc/fstab.

I should have looked at it first. /mnt/base-us is loop-mounted and this was done in an upstart-script which calls lipc* (can't remember the details - it was late last night).
As I could not find a way to tell the system to mount mmcblk0p5 instead of p4, I restored the original partition table and reflashed mmcblk0p4 (because it was damaged by fdisk). I had some troubles to get the Kindle working again. Could not figure out why - maybe low batteries.

Now it is working again.
Keeping the partition numbering the same seems to be necessary to get Kindle running after repartitioning. Therefore I am thinking about deleting the diags partition putting debian there and leave the rest unchanged. Maybe I am lucky and can boot into Debian without much effort - so to get my "rescue" partition back.

One problem might be the changed file size of mmcblk0p4. I hope the Kindle system recognizes that and handles it correctly.

Any suggestions? Comments?

NiLuJe · 10-30-2012, 02:33 PM

Besides tweaking some upstart jobs, you'll probably have to wrestle the volumd (the daemon handling part of the whole userstore handling, especially the USBMS export) settings to point to the right stuff. AFAIR, the settings are spread around between upstart scripts/resources and the kdb.

(So, that's a resounding 'no' on the system automagically handling a different part name/size

).

twobob · 10-30-2012, 02:34 PM

Knc1 has the information required (I think) more or less now to resize the drives.

the rescue partition is useful for - well, rescuing, but I guess that is up to you.

Oddly I was thinking almost exactly the same thing when I read this (that I would like to amend rootfs size),

Many of the armel applications are happy to run on FAT with a bit of re-factoring.
There is already an X. and supporting libs are easily built via buildroot.

what is it about Debian that you really want? Packages manager perhaps would be cool

I am interested to know.

anyways those are my thoughts. KNC1 might know.

knc1 · 10-30-2012, 07:06 PM

The u-boot firmware does not "do extended partitions" -
At least not the u-boot build in the early Kindle images I have looked at.

**BUT**, it should be possible to move the partition boundary between p3 and the huge p4, giving you a larger /usr/local (or /var/local - I forget its name at the moment).
**should** nobody has tried it and reported back -
Here is your chance to grab some "Bragging Rights" (or Karma).

eureka · 10-30-2012, 08:05 PM

p4 has an [embedded] partition table on it's own. You can edit this table, shrink userstore parition (it's a single partition embedded in p4) from the end, then add a new primary partition into freed space of p4. Then create a loopback device for this new partition and mount this new loopback device (just as it's done with existing userstore parition).

Some additional tasks will be not so easy, but not so hard either. Take a look at /etc/upstart/userstore, /usr/sbin/mntus and /var/local/system/mntus.params.

Honestly, I can't say anything more clear. I didn't try it. It could be tedious. But via this way you'll get separate partition with keeping userstore partition (read: without disabling capability of exporting it through USB) and little (if any) changing of original KT configuration files. Also you can get much more size comparing with replacing of diags.

Good luck!

knc1 · 10-30-2012, 08:34 PM

@eureka: Might be a better idea than mine. Also, should have much less impact on the over-all system (just be sure to leave the current partition as the first entry in the table).

Plus, it does not need to be formatted FAT.
Just do everything in the same block size increments the Kindle uses (8096bytes) - which also maintains erase block alignment.

EternalCyclist · 10-31-2012, 02:10 AM

If had read Eureka's post in time, I would have tried that. But I was already in troubles at that time. "Was" because now it works - well, almost.

What I did up to now
I kept the diags partition and just resized and moved mmcblk0p4.

Save the beginning of /dev/mmcblk0.
.. assuming that there is the partition table and other data I might have to reflash sometimes.

Spoiler:

Unmount mmcblk0p4

Spoiler:

Repartition
Using fdisk I moved the start of /dev/mmcblk0p4. Moving up the start instead of moving down the end is neccessary, as I want to resize /dev/mmcblk0p2 in order to keep partition numbering the same.

The new partition table:

Spoiler:

After writing the partition table fdisk said:
"kernel still has old partition table. cannot fdisk /dev/mmcblk0p4".
True.

Code:

fdisk -l /dev/mmcblk0p4

still prints the original partition table.
Thus writing of that secondary partition table is not possible without reboot. As I doubted that the Kindle will come up with a damaged partition, I dd'ed the raw data of the beginning of the original partition to the start of the resized one.

Spoiler:

THAT WAS A MISTAKE! Because the partition table has wrong size and the vfat file system ist damaged.
I rather should have created a new mmcblk0p4 with the new size at the PC. Formatting it there and even copying the original data to that system and dd|nc'ing it to the new Kindle partition.

After rebooting the Kindle hanged. dmesg on the PC printed some infos about new scssi device but did not mount it. Almost the same as I had the night before after restoring the old partition (see first post). But this time I was at least able to put the Kindle in bootloader mode and reboot it with imx_usb. But it hangs, regardless of main or diags booting. Leaving it, going to sleep.

This morning the Kindle is working again. After setting it in USB device mode the PC even mounted the damaged partition table. Of course with some error messages.

Spoiler:

fdisk on the PC shows the original (now wrong) partition table.

Spoiler:

So far...
I think I will try to format the partition from the PC. At least in diags mode it should do no harm.

twobob · 10-31-2012, 05:55 AM

Fascinating. edge of my seat stuff....

I don't have anything to add - other than register my excitement. : D

solid notes! much obliged so far,

geekmaster · 10-31-2012, 10:01 AM

You may need to adjust the values in /var/local/system/mntusb.params (I think) to match your new partition layout...

knc1 · 10-31-2012, 10:04 AM

When could you ever resize a mounted FAT partition?
You gotta unmount it before you can fdisk it.
And remember, before you can unmount it, you have to deal with the FUSE file system that is using it.

EternalCyclist · 10-31-2012, 01:42 PM

Quote:

Originally Posted by knc1

When could you ever resize a mounted FAT partition?

You're right, but your advice came to late. When I moved and resized mmcblk0p4 I unmounted it on the Kindle as described in the first post.

Now, when I tried to correct the wrong size of mmcblk0p4p1 FROM HOST PC, I unmonted it ON HOST PC. How silly!

After

Code:

mkfs.vfat /dev/sdc1; mount -t vfat /dev/sdc1 /mnt/kindle;

I copied my data back to the Kindle. Everything seemed to work. After rebooting from diags to main PC mounted Kindle disk without complaints. BUT /mt/kindle was in factory preset state.

Of course, as knc1 said, I should have unmounted /mnt/us and /mnt/base-us ON KINDLE before fdisking.

Copying data again to kindle. Reboot. Data still there. Maybe I should do an integrity check ...

But there's more to do:
Now I will move mmcpblkp03 up to have free space to resize mmcblkp02.

EternalCyclist · 10-31-2012, 02:04 PM

Quote:

Originally Posted by geekmaster

You may need to adjust the values in /var/local/mntusb.params (I think) to match your new partition layout...

On my K5 I have only /var/local/system/mntusb.params and the first line says
"# auto-generated file -- do not modify!"

then:

Code:

# computed values
MNTUS_PART_START=16
MNTUS_PART_SIZE=1257496
MNTUS_PART_OFFSET=8192

The computation is actually pretty good. ;-)

PART_SIZE matches fdisk size output.

PART_OFFSET is the position of the secondary FAT.

Not matching the second part of mntusb.params could bring some speed loss - I gess.

Code:

# constant values
# FAT32 fs
MNTUS_FATSIZE=32
# Align fs data to 4MB boundary
MNTUS_ALIGNMENT_MB=4
# Use 8k cluster size for better write performance
MNTUS_SECTORS_PER_CLUSTER=16

geekmaster · 10-31-2012, 02:14 PM

Quote:

Originally Posted by EternalCyclist

On my K5 I have only /var/local/system/mntusb.params and the first line says

Code:

"# auto-generated file -- do not modify!"

I had intented to type /system in that line. I actually remember thinking "/system" while I was typing it. My typing accuracy is not so good these days. I corrected my post...

The "auto generated" file is only generated when the startup scripts cannot mount the partition in FAT mode, in which case they delete that partition, create a new one, and repopulate it with default files.

That mntusb.params file happens to be one that is also written by some jailbreaks (and debricking scripts), so it could also get changed to values different from your own when installing a jailbreak (or debricking)...

eureka · 10-31-2012, 03:38 PM

I've tried to reparition /dev/mmcblk0p4 (on Kindle Touch 5.1.2). So, here is how-to.

Make BACKUP of your Kindle userstore parition (i.e. /mnt/us). It will be destroyed!
stop framework. It's not strictly required, but framework is the most obvious consumer of userstore parition content, so let's disable it just in paranoia considerations:
Code:
```
[root@kindle root]# stop framework
```

unmount userstore parition. Also check if /mnt/us and/or /mnt/base-us were/are mounted:

Code:

[root@kindle root]# mount | grep -c us
2

Code:

[root@kindle root]# /etc/upstart/userstore stop

Code:

[root@kindle root]# mount | grep -c us
0

make copy of userstore script:

Code:

[root@kindle root]# cp /etc/upstart/userstore /var/tmp/root/userstore

change copy of userstore script (UPD: read this beforehand). The changed script will create two partitions at /dev/mmcbk0p4: first is the default Kindle userstore partition (already formatted), second is unformatted free space. Size of first parition could be changed in line with definition of PART_SIZE variable. In this diff, it's set to 1GB (1024 * 1024 * 1024 is 1GB in bytes and 512 is sector size):

PHP Code:

--- /etc/upstart/userstore +++ /var/tmp/root/userstore @@ -29,7 +29,8 @@ PART_START=${_TRACKSIZE} # try to read back the existing partition size - PART_SIZE=`sfdisk --force -l ${MNTUS_DEV} | awk '$1 ~ '/${_BASE_MNTUS_DEV}p1/\ '{ print $5 }'` + PART_SIZE=`expr 1024 \* 1024 \* 1024 \/ 512` + NEXT_PART_START=`expr ${PART_START} \+ ${PART_SIZE}` if [ -z "${PART_SIZE}" ]; then _CREATE=1 @@ -41,7 +42,8 @@ # create the volume partition sfdisk -q --force -uS ${MNTUS_DEV} <<EOI -${PART_START},,b +${PART_START},${PART_SIZE},b +${NEXT_PART_START} EOI # read back the created partition size @@ -237,8 +239,6 @@ # returned status is that of the called routine case "$1" in - start) start_us ;; - stop) stop_us ;; - init) init_us ;; - *) echo "usage: $0 [start|stop|init]" ; exit 1 ;; + repartition) init_us "create";; + *) echo "usage: $0 repartition" ; exit 1 ;; esac
did you backup your userstore parition? If not, backup it right now!

execute changed userstore script (output is skipped):

Code:

[root@kindle root]# sh /var/tmp/root/userstore repartition

mount new Kindle userstore parition:

Code:

[root@kindle root]# /etc/upstart/userstore start

check for changes:

Code:

[root@kindle root]# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               340.2M    232.9M     90.3M  72% /
tmpfs                   124.8M     72.0K    124.8M   0% /dev
tmpfs                   124.8M         0    124.8M   0% /dev/shm
tmpfs                    32.0M    340.0K     31.7M   1% /var
/dev/mmcblk0p3           31.0M     16.2M     13.1M  55% /var/local
/dev/loop/0            1018.0M    552.0K   1017.5M   0% /mnt/base-us
fsp                    1018.0M    552.0K   1017.5M   0% /mnt/us

Code:

[root@kindle root]# sfdisk --force -l /dev/mmcblk0p4

Disk /dev/mmcblk0p4: 105536 cylinders, 4 heads, 16 sectors/track
Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/mmcblk0p4p1          0+  32768-  32768    1048576    b  W95 FAT32
/dev/mmcblk0p4p2      32768+ 105535   72768-   2328568   83  Linux
/dev/mmcblk0p4p3          0       -       0          0    0  Empty
/dev/mmcblk0p4p4          0       -       0          0    0  Empty

start framework:
Code:
```
[root@kindle root]# start framework
```

New userstore parition survives reboot and works as expected when Kindle connected to computer.

Your new partition (i.e. new free space) could be destroyed by system userstore script in some rare cases:

if size of /dev/mmcbk0p4p1 will be 0 (as reported by sfdisk --force -l /dev/mmcblk0p4),
if /usr/sbin/mntus mount will return failure (not zero exit code).

This possibility of destroying could be avoided with slight changes in /etc/upstart/userstore, but I think these cases are really rare, so they doesn't matter.

So, now you have free space. It should be formatted and mounted as loopback device. (Maybe I'll describe further setup a bit later, if nobody will do it before me...)

eureka · 10-31-2012, 10:19 PM

Let's see how filesystem data should be aligned and what block size was chosen for stock filesystems :

Code:

[root@kindle root]# grep Align /etc/upstart/userstore 
# Align fs data to 4MB boundary
		# Align FAT fs data on 4 MB boundary to improve eMMC performance

Code:

[root@kindle root]# grep cluster /var/local/system/mntus.params 
# Use 8k cluster size for better write performance

Code:

[root@kindle root]# for i in 1 2 3; do tune2fs -l /dev/mmcblk0p$i | grep 'Block size:'; done
Block size:               1024
Block size:               1024
Block size:               1024

I think, our ext3 filesystem should be aligned on 4MB (4194304 = 4 * 1024 * 1024) and have block of 1024 bytes.

Let's find offset (in bytes) of start of our new free space (UPD: read this beforehand). Offset of /dev/mmcblk0p4 (in sectors) could be read with cat /sys/class/block/mmcblk0p4/start. Offset of /dev/mmcblk0p4p2 (in sectors, relative to start of /dev/mmcblk0p4) could be found in output of sfdisk -uS -l --force /dev/mmcblk0p4. Sector size is 512 bytes.

Code:

[root@kindle root]# expr 512 \* \( \
>   $(sfdisk -uS -l --force /dev/mmcblk0p4 | awk '/mmcblk0p4p2/ {print $2}') \
>   \+ $(cat /sys/class/block/mmcblk0p4/start) \
> \)
1574969344

This offset isn't aligned on 4MB boundary. To find new, aligned offset, we should divide found offset on 4MB, round the answer to most closest larger integer and multiply rounded answer on 4MB. In Python 3.x:

Code:

>>> round(1574969344 / 4194304) * 4194304
1577058304

And then let's convert found absolute offset (from start of eMMC device) to relative offset (from start of /dev/mmcblk0p4) required for losetup:

Code:

[root@kindle root]# expr 1577058304 - 512 \* $(cat /sys/class/block/mmcblk0p4/start)
1075838976

Userstore parition is mounted to /dev/loop/0. All other loop devices are free (UPD: not quite right, read here). So let's select /dev/loop/1 as device for our new parition, mount free space as loopback device and format it (output is skipped):

Code:

[root@kindle root]# losetup -o 1075838976 /dev/loop/1 /dev/mmcblk0p4
[root@kindle root]# mkfs.ext3 -b 1024 /dev/loop/1
[root@kindle root]# losetup -d /dev/loop/1

To mount our new filesystem:

Code:

[root@kindle root]# losetup -o 1075838976 /dev/loop/1 /dev/mmcblk0p4
[root@kindle root]# mount /dev/loop/1 /somewhere

To unmount:

Code:

[root@kindle root]# umount /somewhere
[root@kindle root]# losetup -d /dev/loop/1

10-30-2012, 02:26 PM	#1
EternalCyclist Member Posts: 17 Karma: 17948 Join Date: Oct 2012 Device: KT	Repartitioning Kindle Filesystem In order to have a separate partition for Debian, I tried to repartition mmcblk0p4. * umount /mnt/us * umount /mnt/base-us * fdisk /dev/mmcblk0p4 deleting partition 4 adding new extended partition adding new partition for us adding new partition for Debian ** writing partition table Then I wanted to modify /etc/fstab. I should have looked at it first. /mnt/base-us is loop-mounted and this was done in an upstart-script which calls lipc* (can't remember the details - it was late last night). As I could not find a way to tell the system to mount mmcblk0p5 instead of p4, I restored the original partition table and reflashed mmcblk0p4 (because it was damaged by fdisk). I had some troubles to get the Kindle working again. Could not figure out why - maybe low batteries. Now it is working again. Keeping the partition numbering the same seems to be necessary to get Kindle running after repartitioning. Therefore I am thinking about deleting the diags partition putting debian there and leave the rest unchanged. Maybe I am lucky and can boot into Debian without much effort - so to get my "rescue" partition back. One problem might be the changed file size of mmcblk0p4. I hope the Kindle system recognizes that and handles it correctly. Any suggestions? Comments?

10-30-2012, 02:34 PM	#3
twobob ( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Týr Posts: 6,586 Karma: 6299991 Join Date: Jun 2012 Location: uti gratia usura (Yao ying da ying; Mo ying da yieng) Device: PW-WIFI\|K5-3G+WIFI\| K4\|K3-3G\|DXG\|K2\| Rooted Nook Touch	Knc1 has the information required (I think) more or less now to resize the drives. the rescue partition is useful for - well, rescuing, but I guess that is up to you. Oddly I was thinking almost exactly the same thing when I read this (that I would like to amend rootfs size), Many of the armel applications are happy to run on FAT with a bit of re-factoring. There is already an X. and supporting libs are easily built via buildroot. what is it about Debian that you really want? Packages manager perhaps would be cool I am interested to know. anyways those are my thoughts. KNC1 might know. Last edited by twobob; 10-30-2012 at 02:39 PM. Reason: (that I would like to amend rootfs size)

10-30-2012, 08:34 PM	#6
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	@eureka: Might be a better idea than mine. Also, should have much less impact on the over-all system (just be sure to leave the current partition as the first entry in the table). Plus, it does not need to be formatted FAT. Just do everything in the same block size increments the Kindle uses (8096bytes) - which also maintains erase block alignment. Last edited by knc1; 10-30-2012 at 08:36 PM.

10-31-2012, 10:01 AM	#9
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773668 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	You may need to adjust the values in /var/local/system/mntusb.params (I think) to match your new partition layout... Last edited by geekmaster; 10-31-2012 at 02:11 PM.

10-31-2012, 03:38 PM	#14
eureka but forgot what it's like Posts: 741 Karma: 2345678 Join Date: Dec 2011 Location: north (by northwest) Device: Kindle Touch	I've tried to reparition /dev/mmcblk0p4 (on Kindle Touch 5.1.2). So, here is how-to. Make BACKUP of your Kindle userstore parition (i.e. /mnt/us). It will be destroyed! stop framework. It's not strictly required, but framework is the most obvious consumer of userstore parition content, so let's disable it just in paranoia considerations: Code: [root@kindle root]# stop framework unmount userstore parition. Also check if /mnt/us and/or /mnt/base-us were/are mounted: Code: [root@kindle root]# mount \| grep -c us 2 Code: [root@kindle root]# /etc/upstart/userstore stop Code: [root@kindle root]# mount \| grep -c us 0 make copy of userstore script: Code: [root@kindle root]# cp /etc/upstart/userstore /var/tmp/root/userstore change copy of userstore script (UPD: read this beforehand). The changed script will create two partitions at /dev/mmcbk0p4: first is the default Kindle userstore partition (already formatted), second is unformatted free space. Size of first parition could be changed in line with definition of PART_SIZE variable. In this diff, it's set to 1GB (1024 1024 * 1024* is 1GB in bytes and 512 is sector size): PHP Code: --- /etc/upstart/userstore +++ /var/tmp/root/userstore @@ -29,7 +29,8 @@ PART_START=${_TRACKSIZE} # try to read back the existing partition size - PART_SIZE=`sfdisk --force -l ${MNTUS_DEV} \| awk '$1 ~ '/${_BASE_MNTUS_DEV}p1/\ '{ print $5 }'` + PART_SIZE=`expr 1024 \* 1024 \* 1024 \/ 512` + NEXT_PART_START=`expr ${PART_START} \+ ${PART_SIZE}` if [ -z "${PART_SIZE}" ]; then _CREATE=1 @@ -41,7 +42,8 @@ # create the volume partition sfdisk -q --force -uS ${MNTUS_DEV} <<EOI -${PART_START},,b +${PART_START},${PART_SIZE},b +${NEXT_PART_START} EOI # read back the created partition size @@ -237,8 +239,6 @@ # returned status is that of the called routine case "$1" in - start) start_us ;; - stop) stop_us ;; - init) init_us ;; - ) echo "usage: $0 [start\|stop\|init]" ; exit 1 ;; + repartition) init_us "create";; + ) echo "usage: $0 repartition" ; exit 1 ;; esac did you backup your userstore parition? If not, backup it right now! execute changed userstore script (output is skipped): Code: [root@kindle root]# sh /var/tmp/root/userstore repartition mount new Kindle userstore parition: Code: [root@kindle root]# /etc/upstart/userstore start check for changes: Code: [root@kindle root]# df -h Filesystem Size Used Available Use% Mounted on /dev/root 340.2M 232.9M 90.3M 72% / tmpfs 124.8M 72.0K 124.8M 0% /dev tmpfs 124.8M 0 124.8M 0% /dev/shm tmpfs 32.0M 340.0K 31.7M 1% /var /dev/mmcblk0p3 31.0M 16.2M 13.1M 55% /var/local /dev/loop/0 1018.0M 552.0K 1017.5M 0% /mnt/base-us fsp 1018.0M 552.0K 1017.5M 0% /mnt/us Code: [root@kindle root]# sfdisk --force -l /dev/mmcblk0p4 Disk /dev/mmcblk0p4: 105536 cylinders, 4 heads, 16 sectors/track Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/mmcblk0p4p1 0+ 32768- 32768 1048576 b W95 FAT32 /dev/mmcblk0p4p2 32768+ 105535 72768- 2328568 83 Linux /dev/mmcblk0p4p3 0 - 0 0 0 Empty /dev/mmcblk0p4p4 0 - 0 0 0 Empty start framework: Code: [root@kindle root]# start framework New userstore parition survives reboot and works as expected when Kindle connected to computer. Your new partition (i.e. new free space) could be destroyed by system userstore script in some rare cases: if size of /dev/mmcbk0p4p1 will be 0 (as reported by sfdisk --force -l /dev/mmcblk0p4), if /usr/sbin/mntus mount will return failure (not zero exit code). This possibility of destroying could be avoided with slight changes in /etc/upstart/userstore, but I think these cases are really rare, so they doesn't matter. So, now you have free space. It should be formatted and mounted as loopback device. (Maybe I'll describe further setup a bit later, if nobody will do it before me...) Last edited by eureka; 11-05-2012 at 09:03 AM. Reason: add link to alternative userstore script diff

10-30-2012, 02:33 PM	#2
NiLuJe BLAM! Posts: 13,506 Karma: 26047190 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Besides tweaking some upstart jobs, you'll probably have to wrestle the volumd (the daemon handling part of the whole userstore handling, especially the USBMS export) settings to point to the right stuff. AFAIR, the settings are spread around between upstart scripts/resources and the kdb. (So, that's a resounding 'no' on the system automagically handling a different part name/size ).

10-30-2012, 07:06 PM	#4
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	The u-boot firmware does not "do extended partitions" - At least not the u-boot build in the early Kindle images I have looked at. BUT, it should be possible to move the partition boundary between p3 and the huge p4, giving you a larger /usr/local (or /var/local - I forget its name at the moment). should nobody has tried it and reported back - Here is your chance to grab some "Bragging Rights" (or Karma).

10-30-2012, 08:05 PM	#5
eureka but forgot what it's like Posts: 741 Karma: 2345678 Join Date: Dec 2011 Location: north (by northwest) Device: Kindle Touch	p4 has an [embedded] partition table on it's own. You can edit this table, shrink userstore parition (it's a single partition embedded in p4) from the end, then add a new primary partition into freed space of p4. Then create a loopback device for this new partition and mount this new loopback device (just as it's done with existing userstore parition). Some additional tasks will be not so easy, but not so hard either. Take a look at /etc/upstart/userstore, /usr/sbin/mntus and /var/local/system/mntus.params. Honestly, I can't say anything more clear. I didn't try it. It could be tedious. But via this way you'll get separate partition with keeping userstore partition (read: without disabling capability of exporting it through USB) and little (if any) changing of original KT configuration files. Also you can get much more size comparing with replacing of diags. Good luck!

10-31-2012, 05:55 AM	#8
twobob ( ͡° ͜ʖ ͡°){ʇlnɐɟ ƃǝs}Týr Posts: 6,586 Karma: 6299991 Join Date: Jun 2012 Location: uti gratia usura (Yao ying da ying; Mo ying da yieng) Device: PW-WIFI\|K5-3G+WIFI\| K4\|K3-3G\|DXG\|K2\| Rooted Nook Touch	Fascinating. edge of my seat stuff.... I don't have anything to add - other than register my excitement. : D solid notes! much obliged so far,

10-31-2012, 10:04 AM	#10
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	When could you ever resize a mounted FAT partition? You gotta unmount it before you can fdisk it. And remember, before you can unmount it, you have to deal with the FUSE file system that is using it.

10-31-2012, 10:19 PM	#15
eureka but forgot what it's like Posts: 741 Karma: 2345678 Join Date: Dec 2011 Location: north (by northwest) Device: Kindle Touch	Let's see how filesystem data should be aligned and what block size was chosen for stock filesystems : Code: [root@kindle root]# grep Align /etc/upstart/userstore # Align fs data to 4MB boundary # Align FAT fs data on 4 MB boundary to improve eMMC performance Code: [root@kindle root]# grep cluster /var/local/system/mntus.params # Use 8k cluster size for better write performance Code: [root@kindle root]# for i in 1 2 3; do tune2fs -l /dev/mmcblk0p$i \| grep 'Block size:'; done Block size: 1024 Block size: 1024 Block size: 1024 I think, our ext3 filesystem should be aligned on 4MB (4194304 = 4 * 1024 * 1024) and have block of 1024 bytes. Let's find offset (in bytes) of start of our new free space (UPD: read this beforehand). Offset of /dev/mmcblk0p4 (in sectors) could be read with cat /sys/class/block/mmcblk0p4/start. Offset of /dev/mmcblk0p4p2 (in sectors, relative to start of /dev/mmcblk0p4) could be found in output of sfdisk -uS -l --force /dev/mmcblk0p4. Sector size is 512 bytes. Code: [root@kindle root]# expr 512 \* \( \ > $(sfdisk -uS -l --force /dev/mmcblk0p4 \| awk '/mmcblk0p4p2/ {print $2}') \ > \+ $(cat /sys/class/block/mmcblk0p4/start) \ > \) 1574969344 This offset isn't aligned on 4MB boundary. To find new, aligned offset, we should divide found offset on 4MB, round the answer to most closest larger integer and multiply rounded answer on 4MB. In Python 3.x: Code: >>> round(1574969344 / 4194304) * 4194304 1577058304 And then let's convert found absolute offset (from start of eMMC device) to relative offset (from start of /dev/mmcblk0p4) required for losetup: Code: [root@kindle root]# expr 1577058304 - 512 \* $(cat /sys/class/block/mmcblk0p4/start) 1075838976 Userstore parition is mounted to /dev/loop/0. All other loop devices are free (UPD: not quite right, read here). So let's select /dev/loop/1 as device for our new parition, mount free space as loopback device and format it (output is skipped): Code: [root@kindle root]# losetup -o 1075838976 /dev/loop/1 /dev/mmcblk0p4 [root@kindle root]# mkfs.ext3 -b 1024 /dev/loop/1 [root@kindle root]# losetup -d /dev/loop/1 To mount our new filesystem: Code: [root@kindle root]# losetup -o 1075838976 /dev/loop/1 /dev/mmcblk0p4 [root@kindle root]# mount /dev/loop/1 /somewhere To unmount: Code: [root@kindle root]# umount /somewhere [root@kindle root]# losetup -d /dev/loop/1 Last edited by eureka; 11-05-2012 at 09:06 AM. Reason: all stock loop devices are busy, in fact

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PRS-T1 Questions about repartitioning	simongee	Sony Reader Dev Corner	47	11-06-2012 05:07 AM
Kindle Touch: Bricked and readonly filesystem	pmugabi	Kindle Developer's Corner	6	09-17-2012 01:50 AM
PRS-T1 Completed guide for repartitioning.	homeos	Sony Reader Dev Corner	20	04-05-2012 11:54 AM
PB360 Filesystem error	ArchCarrier	PocketBook	4	06-06-2010 08:46 AM
Stock kindle 2 filesystem (2.0.3 or newer preferred)	eousphoros	Kindle Developer's Corner	10	02-17-2010 08:40 PM