[Paperwhite] Which hacks are working?

[NiLuJe]

@ixtab: ... And now you went and ruined my incentive to work on usbnet, thanks! .

Kidding, I'll look into it tomorrow (jbpatch, that is ^^) .

[Akirainblack]

Originally Posted by geekmaster

Isn't the first thing on the van also the LAST thing off the van? I would think that the last thing on, right there on the top of the pile, would be the first thing off.

As I said, first thing on that van to be delivered. NOT
It'll be the first thing put on the van.

[antaril]

is there an "fbKindle" Touch version out there that work on the PW?

[back2iam]

Please understand my poor description. I am a not navtive speeker.

I have tried to change file 't1_timeout' on newly jailbroken PW with WinSCP. But failed.
I don't know why is that. I could successfuly changed that same file on Kindle Touch instantly after jailbreaking.

Error Message was "READ-ONLY FILE SYSTEM."

Thank you in advance.

[geekmaster]

It is my understanding that base-* mounts are supposed to be read-only. Use mmc, not base-mmc.

[knc1]

Originally Posted by back2iam

Please understand my poor description. I am a not navtive speeker.

I have tried to change file 't1_timeout' on newly jailbroken PW with WinSCP. But failed.
I don't know why is that. I could successfuly changed that same file on Kindle Touch instantly after jailbreaking.

Error Message was "READ-ONLY FILE SYSTEM."

Thank you in advance.

So use the:
mount
command to list the mounts and the current attribute settings.
Use that information to make up the command to make the file system r/w.

[NiLuJe]

The rootfs has *always* been ro in every Kindle device.

It only switches rw for very, very short periods of time for certain events, and during the update process.

(Also, why in the hell are you relying on the base-mmc mount? That's not even mounted by default in main o_O)

EDIT: Besides, for what you're trying to do, I'd recommend using kdb set on the CLI instead of messing with the DB manually.

[knc1]

Originally Posted by NiLuJe

The rootfs has *always* been ro in every Kindle device.

It only switches rw for very, very short periods of time for certain events, and during the update process.

True.
But this is a Paperwhite with its collection of loop mounted, ro file systems.
I did not know if the path the O.P. wrote about was into one of the ro file systems, so I had to ask for the output of: mount

[NiLuJe]

@knc1: For future ref:

/dev/root               340.2M    229.2M     93.9M  71% /
tmpfs                   125.1M     60.0K    125.0M   0% /dev
tmpfs                   125.1M         0    125.1M   0% /dev/shm
tmpfs                   190.0M    300.0K    189.7M   0% /var
/dev/loop/2             216.0K    216.0K         0 100% /lib/firmware/cyttsp
/dev/loop/3               2.5M      2.5M         0 100% /usr/share/X11/xkb
/dev/loop/4              72.9M     72.9M         0 100% /usr/java/lib/fonts
/dev/loop/5               1.3M      1.3M         0 100% /etc/kdb.src
/dev/loop/6               7.9M      7.9M         0 100% /usr/lib/locale
/dev/loop/7               7.7M      7.7M         0 100% /usr/share/keyboard
/dev/mmcblk0p3           62.0M     17.7M     41.1M  30% /var/local
fsp                       1.4G     49.2M      1.3G   4% /mnt/us
/dev/loop/0               1.4G     49.2M      1.3G   4% /mnt/base-us

rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,nodiratime,data=writeback 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
tmpfs /var tmpfs rw,relatime,size=194560k 0 0
/dev/loop/2 /lib/firmware/cyttsp cramfs ro,noatime,nodiratime 0 0
/dev/loop/3 /usr/share/X11/xkb cramfs ro,noatime,nodiratime 0 0
/dev/loop/4 /usr/java/lib/fonts cramfs ro,noatime,nodiratime 0 0
/dev/loop/5 /etc/kdb.src cramfs ro,noatime,nodiratime 0 0
/dev/loop/6 /usr/lib/locale cramfs ro,noatime,nodiratime 0 0
/dev/loop/7 /usr/share/keyboard cramfs ro,noatime,nodiratime 0 0
/dev/mmcblk0p3 /var/local ext3 rw,relatime,errors=continue,data=writeback 0 0
fsp /mnt/us fuse.fsp rw,nosuid,nodev,noatime,user_id=0,group_id=0 0 0
/dev/loop/0 /mnt/base-us vfat rw,noexec,noatime,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

(That's during the update process, hence the rw rootfs).

... Which reminds me: Yup, the KDB DB is in a loop mounted cramfs on the PW, so, yeah, use kdb set. [You'll probably have to remount said cramfs rw, though].

[knc1]

Originally Posted by NiLuJe

@knc1: For future ref:

/dev/root               340.2M    229.2M     93.9M  71% /
tmpfs                   125.1M     60.0K    125.0M   0% /dev
tmpfs                   125.1M         0    125.1M   0% /dev/shm
tmpfs                   190.0M    300.0K    189.7M   0% /var
/dev/loop/2             216.0K    216.0K         0 100% /lib/firmware/cyttsp
/dev/loop/3               2.5M      2.5M         0 100% /usr/share/X11/xkb
/dev/loop/4              72.9M     72.9M         0 100% /usr/java/lib/fonts
/dev/loop/5               1.3M      1.3M         0 100% /etc/kdb.src
/dev/loop/6               7.9M      7.9M         0 100% /usr/lib/locale
/dev/loop/7               7.7M      7.7M         0 100% /usr/share/keyboard
/dev/mmcblk0p3           62.0M     17.7M     41.1M  30% /var/local
fsp                       1.4G     49.2M      1.3G   4% /mnt/us
/dev/loop/0               1.4G     49.2M      1.3G   4% /mnt/base-us

rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,nodiratime,data=writeback 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
tmpfs /var tmpfs rw,relatime,size=194560k 0 0
/dev/loop/2 /lib/firmware/cyttsp cramfs ro,noatime,nodiratime 0 0
/dev/loop/3 /usr/share/X11/xkb cramfs ro,noatime,nodiratime 0 0
/dev/loop/4 /usr/java/lib/fonts cramfs ro,noatime,nodiratime 0 0
/dev/loop/5 /etc/kdb.src cramfs ro,noatime,nodiratime 0 0
/dev/loop/6 /usr/lib/locale cramfs ro,noatime,nodiratime 0 0
/dev/loop/7 /usr/share/keyboard cramfs ro,noatime,nodiratime 0 0
/dev/mmcblk0p3 /var/local ext3 rw,relatime,errors=continue,data=writeback 0 0
fsp /mnt/us fuse.fsp rw,nosuid,nodev,noatime,user_id=0,group_id=0 0 0
/dev/loop/0 /mnt/base-us vfat rw,noexec,noatime,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

(That's during the update process, hence the rw rootfs).

... Which reminds me: Yup, the KDB DB is in a loop mounted cramfs on the PW, so, yeah, use kdb set. [You'll probably have to remount said cramfs rw, though].

The cramFS file system does not have a "write mode";
sorry about that.

Whatever "kdb set" is, it must be doing its thing to a ram copy of the fs.

Guess we will have to write up a HowTo on reading and re-building replacement cramFS systems.

It is relatively easy on *nix but I understand that the Windows tools sort of suck.

Note also (HEY - twobob): the vfat partition is now mounted "noexec".
Just another challenge there at out smarting lab126.

[NiLuJe]

@knc1: Ah, thanks for the cramfs info!

Also, note that it's the base-us loop that's mounted noexec (and has been for a long time, AFAIR, that's not PW specific), the actual fuse mount on us is exec friendly .

[knc1]

Originally Posted by NiLuJe

@knc1: Ah, thanks for the cramfs info!

Also, note that it's the base-us loop that's mounted noexec (and has been for a long time, AFAIR, that's not PW specific), the actual fuse mount on us is exec friendly .

They must have missed that one (along with "noexec" on /var/local).

But already we are seeing posts about font changes on the Paperwhite:

/dev/loop/4 /usr/java/lib/fonts cramfs ro,noatime,nodiratime 0 0

So unless the system has another look-up place for alternate fonts, we still get to write up that "HowTo Read and Rebuild cramFS" image files.

One starting point (with its included README file):
http://sourceforge.net/projects/cramfs/
But the tools should be available with any Linux distro.

I don't know if a cramFS image can be bspatched - I never heard of anyone trying it.