Repartitioning Kindle Filesystem

[geekmaster]

Originally Posted by eureka

I executed exactly that command (just with -o <offset>, without -o loop) on KT and there was new mounted loop device in mount output. ...

I just did "mount /dev/mmcblk0p2 /mnt/mmc" on my PW, and the ONLY extra line I saw in my mounts was "/dev/mmcblk0p2 on /mnt/mmc type ext3 (rw,relatime,data=writeback)".

I still need to try it on my K5, but I do not expect any loop mount, or I would probably have noticed it long ago...

[eureka]

Originally Posted by geekmaster

I just did "mount /dev/mmcblk0p2 /mnt/mmc" on my PW, and the ONLY extra line I saw in my mounts was "/dev/mmcblk0p2 on /mnt/mmc type ext3 (rw,relatime,data=writeback)".

I still need to try it on my K5, but I do not expect any loop mount, or I would probably have noticed it long ago...

I guess, there is a difference between

mount -o offset=1075838976 /dev/mmcblk0p4 /somehwere

and

mount /dev/mmcblk0p2 /mnt/mmc

Did you try mount with -o offset=<offset>?

Originally Posted by man mount | grep -A1 offset

This type of mount knows about four options, namely loop, offset,
sizelimit and encryption, that are really options to losetup(8). If

[geekmaster]

Originally Posted by eureka

I guess, there is a difference between

mount -o offset=1075838976 /dev/mmcblk0p4 /somehwere

and

mount /dev/mmcblk0p2 /mnt/mmc

Did you try mount with -o offset=<offset>?

Not recently... I did the offset for p4 when I was developing my mntusb.params for the Select Boot thread, and I did not notice a loop mount. Perhaps the offset requires a loop mount. I will have to check it out when I get time.

I only did a quick "loop check" for P2, while installing diags SSH into my PW...

[eureka]

Originally Posted by geekmaster

Perhaps the offset requires a loop mount.

That excerpt from man mount posted in my answer suggests that offset option is just passed through to losetup, so it means that losetup is invoked by mount -o offset=<offset> before real mounting.

[geekmaster]

Originally Posted by eureka

That excerpt from man mount posted in my answer suggests that offset option is just passed through to losetup, so it means that losetup is invoked by mount -o offset=<offset> before real mounting.

Ahh... I missed that. It does the offset mount (hidden) in a loop mount. I will look for that next time I play with mntusb.params... Thanks for the enlightenment.

[twobob]

SO. this whole thread kind of petered out there...

Am I to understand the thrust of it say that the Guide by Eternal Cyclist is good?
With the mounting caveats as stated later... or do the notes of Eureka suggest that this needs more thought?

I'm struggling to put it all together.

[geekmaster]

Does loop mounting a partition use less RAM than loop mounting an image file? Multiple people including myself and dasmoover (as I recall) have had issues with a K5 locking up while trying to do anything useful in a loop mounted ext3 (or ext2) image file, such as building packages. Even apt-get can lock up...

Is the method suggested here significantly better? Has anybody tried compiling something significant in a loop mounted debian on a K5?

In the past, I successfully built X11 on a K3 in a loop mounted debian. I had yet to learn the details of eink updates, but at least the build was successful. It took about 12 hours on my K3. It would be interesting to see how long it takes on a K5 (or even if it completes).

Perhaps loop mounting a raw partition would be faster and use less RAM when NOT going through layers of loop mounting an image file on a fuse filesystem, and the vfat support and all that...

[knc1]

Originally Posted by geekmaster

Perhaps loop mounting a raw partition would be faster and use less RAM when NOT going through layers of loop mounting an image file on a fuse filesystem, and the vfat support and all that...

This last paragraph is the key to the behavior -
the number of VFS layers involved.

Using the loop driver to provide a device-to-device layer (although called part of the Virtual File System) is just a device offset calculation operating below the file-to-device layers.

Plus, adding in a user space file system layer - most bets are off.
The kernel can control, and usually recover from, what happens in kernel space (things like potential deadlock paths).
It has no control over what user space does until it makes a call into kernel space.

[eureka]

Originally Posted by twobob

SO. this whole thread kind of petered out there...

Am I to understand the thrust of it say that the Guide by Eternal Cyclist is good?
With the mounting caveats as stated later... or do the notes of Eureka suggest that this needs more thought?

I'm struggling to put it all together.

I provided step-by-step how-to and did it (in all senses) by myself. It's working: right now, on my KT userstore is shrinked to 1GB, "free space" of 2GB is loop-mounted as ext3 filesystem. And that 1GB userstore is still recognized as USB disk when KT is connected to computer. Aso userstore is perfectly seen by all interested parties from KT firmware (framework, volumd, etc.). And there wasn't any changes in KT system scripts on main partition. It's just work and survives reboot.

Originally Posted by geekmaster

Does loop mounting a partition use less RAM than loop mounting an image file? Multiple people including myself and dasmoover (as I recall) have had issues with a K5 locking up while trying to do anything useful in a loop mounted ext3 (or ext2) image file, such as building packages. Even apt-get can lock up...

I thought, solution for lock-up was already found. Wasn't it?

[geekmaster]

Originally Posted by eureka

I provided step-by-step how-to and did it (in all senses) by myself. It's working: right now, on my KT userstore is shrinked to 1GB, "free space" of 2GB is loop-mounted as ext3 filesystem. And that 1GB userstore is still recognized as USB disk when KT is connected to computer. Aso userstore is perfectly seen by all interested parties from KT firmware (framework, volumd, etc.). And there wasn't any changes in KT system scripts on main partition. It's just work and survives reboot.

I thought, solution for lock-up was already found. Wasn't it?

My memory just isn't what it used to be. Thanks for reminding me. I did not USE that trick so it did not stick in my mind.

Apparently, using /mnt/base-us/ instead of /mnt/us/ eliminates some of the fuse overhead while using a loop mounted file when doing it this way. However, it still uses the vfat layer, so it may free up even more RAM to use a raw partition as suggested in this thread.

[twobob]

Originally Posted by eureka

I provided step-by-step how-to and did it (in all senses) by myself. It's working: right now, on my KT userstore is shrinked to 1GB, "free space" of 2GB is loop-mounted as ext3 filesystem. And that 1GB userstore is still recognized as USB disk when KT is connected to computer. Aso userstore is perfectly seen by all interested parties from KT firmware (framework, volumd, etc.). And there wasn't any changes in KT system scripts on main partition. It's just work and survives reboot.

I thought, solution for lock-up was already found. Wasn't it?

Wowzers. That is good news. I will give it a REALLY good read over again then and decide exactly where to spend my storage.

!!! YAY. nice one you lot many thanks

[EternalCyclist]

Originally Posted by twobob

Am I to understand the thrust of it say that the Guide by Eternal Cyclist is good?
With the mounting caveats as stated later... or do the notes of Eureka suggest that this needs more thought?

The method I described works and I am pretty sure, that also Eureka's solution works. The latter has the advantage that you don't need to move all the contents around just to increase mmcblk0p2.

Concerning Eureka's solution: Hiding the new partition by not writing the info to the secondary partitiontable is ok, as long as you always keep in mind that something is there. Adding an offset corrected entry to the secondary partition table should be no problem.

Why I am still hesitating to use Eureka's method on my second Kindle (K4NT): I would like to boot directly into that new partition, but I don't know how or even if this is possible. Using mmcblk0p2 is easier, as I can boot into diags as before.

[eureka]

Originally Posted by EternalCyclist

Why I am still hesitating to use Eureka's method on my second Kindle (K4NT): I would like to boot directly into that new partition, but I don't know how or even if this is possible. Using mmcblk0p2 is easier, as I can boot into diags as before.

The most straightforward way to boot into new parition is changing of init script /sbin/initt on main parition. For example, add mounting of your parition and then change the root fs with /sbin/pivot_root.

[twobob]

[root@kindle interface2]# fdisk /dev/mmcblk0

The number of cylinders for this disk is set to 119296.
There is nothing wrong with that, but this is larger than 1024,
...
Command (m for help): p

Disk /dev/mmcblk0: 3909 MB, 3909091328 bytes
4 heads, 16 sectors/track, 119296 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 1025 12224 358400 83 Linux
/dev/mmcblk0p2 12225 14272 65536 83 Linux
/dev/mmcblk0p3 14273 15296 32768 83 Linux
/dev/mmcblk0p4 15297 119296 3328000 b Win95 FAT32

Command (m for help): q

notes for when I have go at this... that's the 5 then


[root@kindle root]# fdisk /dev/mmcblk0

The number of cylinders for this disk is set to 122112.
Command (m for help): p

Disk /dev/mmcblk0: 4001 MB, 4001366016 bytes
4 heads, 16 sectors/track, 122112 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 121 20921 665628 83 Linux
/dev/mmcblk0p2 20922 21689 24576 83 Linux
/dev/mmcblk0p3 21690 21945 8192 83 Linux
/dev/mmcblk0p4 21946 122112 3205344 b Win95 FAT32

Command (m for help): q

that's on a 3

[knc1]

fdisk -l
(that's: ell)