Kindle Touch/PW1/PW2 5.0.x - 5.4.4.2 JailBreak. Plus FW 5.x USBNetwork.

[NiLuJe]

@williamrochira: Don't. That never really worked well, and it's far more likely to screw up in an horrible way than anything else (it was done in the time of the Kindle touch, which happens to be a nigh-indestructible beast, software-wise). If you *really* want new stuff without the hassle of cross compiling or emulated native compiling, look at twobob & knc1's threads on how to rip stuff out of Debian armel.

The rootfs is mounted ro for very good reasons (the most prominent ones being keeping the sw safe, and that there's almost no room in there). Do not mess with it, unless you know exactly what you're doing and what that entails. The most recent 'I bricked my PW' thread was from someone who didn't think anything wrong would happen. Spoilers: it did. ;p.

[knc1]

Originally Posted by williamrochira

@NiLuJe

Okay then, I guess it's just a waiting game...

However, I have another question for your infinite Kindle-related wisdom! I can't cd into most of the /opt/ subdirectories. Do you know why? It's really frustrating because I just discovered that there's a package manager for the Kindle (https://www.mobileread.com/forums/sho...d.php?t=118472) but I can't install it!

Please do not do that on a PW2 !!!

If you really can't help yourself, and must diddle, buy a used Kindle Touch to play with.

If you really, really must -
Install the current (at the moment 0.3) ARMhf system libraries (they install into user storage - not Amazon filespace) -
Then pick from Debian/Jessy ARMhf packages.

You will have to do a bit of un-packaging, finding dependencies, running patchelf as required - -
**BUT**
You will not be bricking a non-recoverable device.

Originally Posted by williamrochira

I don't understand! I've mounted read/write, I've tried resetting the thing, but no luck. Any thoughts?

Will.

Yes!

You have written the answer yourself:

I don't understand!

STOP NOW!!

- - - -

Just the simplified over-view:

A "filesystem" is something that exists on top of a "backing store".
In a *nix system, two different levels of abstraction.
Either, or both, or neither may be "read only" in nature.

In addition, *nix systems support filesystems that **can not be written** -
sorry, not in their design spec.
they can only be created and read, never written to.

Your PW2 has a large number of such creatures included in its file system tree.

[afterbox]

@NiLuJe @knc1

Thanks guys! I'm glad you're around to stop people like me screwing up our Kindles ;-)

Could either of you give me a link to the latest "threads on how to rip stuff out of Debian armel" ? Because that would be a lifesaver, so many debian packages I want!

Thanks again,
Will.

[knc1]

Originally Posted by williamrochira

@NiLuJe @knc1

Thanks guys! I'm glad you're around to stop people like me screwing up our Kindles ;-)

You are welcome.

It is also nice to find someone that asks when they first run into a problem rather than waiting to post when it is too late.

Originally Posted by williamrochira

Could either of you give me a link to the latest "threads on how to rip stuff out of Debian armel" ? Because that would be a lifesaver, so many debian packages I want!

Thanks again,
Will.

Ripping Debian ARMel packages - -

Most of that was done by twobob, but is pretty well scattered around the forum inside of his various posts.
His work does include scripting to determine the dependencies of a binary.

This process is limited to software from a fairly old Debian release that is compatible with the very old system libraries that are pre-installed on your Kindle.
(Still, that is many thousands of packages)

Ripping Debian ARMhf packages - -

Takes bow, pats self on back...
I have the done the basics of that, but am a long way from finished due to lack of time.
https://www.mobileread.com/forums/sho...d.php?t=240616
Which is a set of the **most recent** Linux system libraries.

The advantage of this project direction, is that it allows the Kindle to concurrently support more than one set of Linux system libraries (only two at the moment, but it is not limited to that).
I.E: Both (Amazon age) ancient applications and very recent applications.

My base installation includes very recent scripting engines (Busybox ash and Lua(Jit) ) but the only scripting is what is hinted at in my notes (and twobob's work).

The time and effort of making up "end-user" scripted tools is a large item.
If the world waits for me, we may all die of old age before I finish that on my own.

Ah, but I can probably find time to help guide someone else in that work.

The same for other members here -
They "know the answers" but do not have time to do the work themselves.
But they are all quick to respond with answers to problems posted by others.

I'll start a different thread for this topic -
If you find time to add to it (even just adding good "how do I" questions) - that would be great.

- - - -

Do not be intimidated -
twobob started with hardly knowing more than the name of the OS: "Linux" and became one of our most prolific contributors in a short amount of time.

[afterbox]

[deleted]

[knc1]

Because you renamed the directory.

https://www.mobileread.com/forums/sho...1&postcount=47

Let me know if you find a typo or other error in that post.

[afterbox]

@knc1

You're a wonderful person ;-) I knew it would be something stupid I'd done!

Just wondering... What does the "exec esys/bin/busybox ash" command achieve? Whether or not I run this, just setting the PATH variable seems to work for me, so is it still necessary?

Last question! This is probably very stupid of me, but adding the PATH setting command to a '.bashrc' or a '.bash_profile' didn't set the path at login. Is there a way to do this?

Thanks,
Will.

[knc1]

Originally Posted by williamrochira

Just wondering... What does the "exec esys/bin/busybox ash" command achieve? Whether or not I run this, just setting the PATH variable seems to work for me, so is it still necessary?

Will.

It replaces the currently executing (very old, Amazon provided) copy of the command line interpreter with the new one.

You will notice the differences when you try to run ash ('sh') scripts.
The old version provided on your Kindle is a real headache to use at times.

[eschwartz]

What about manually setting the PATH in /etc/environment

[afterbox]

@knc1: Ah, okay. So the command still has to be executed every session?

@eschwartz: I'm afraid that /etc/environment didn't work for the PATH variable, and obviously isn't suitable for executing the "exec esys/bin/busybox ash" command. I've also tried /etc/bash/bashrc to no avail.

Any other ideas? I'm thinking I might just put it in a shell script and remembering to run it at login.

Will.

Sidenote: What do people do with the 'control' directory in deb packages? Should I keep 'em?

[NiLuJe]

Wild guess: Try ~/.profile. Drawback: ${HOME} is a tmpfs for root by default.

[afterbox]

Well we're getting somewhere, ~/.profile successfully executed:

cd /mnt/us
exec esys/bin/busybox ash

But echo $PATH returns:

/usr/local/bin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/python/bin

So the export PATH=/mnt/us/esys/bin:/mnt/us/esys/usr/bin:$PATH didn't work...

PS: Same result with a shell script, can't export the PATH variable.

[eschwartz]

Originally Posted by NiLuJe

Wild guess: Try ~/.profile. Drawback: ${HOME} is a tmpfs for root by default.

mntroot rw && sed -i -e "s/\/tmp\/root/\/mnt\/us\/home/" /etc/paswd && mntroot ro

Doesn't seem much of a drawback.

[eschwartz]

Originally Posted by williamrochira

Well we're getting somewhere, ~/.profile successfully executed:

cd /mnt/us
exec esys/bin/busybox ash

But echo $PATH returns:

/usr/local/bin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/python/bin

So the export PATH=/mnt/us/esys/bin:/mnt/us/esys/usr/bin:$PATH didn't work...

PS: Same result with a shell script, can't export the PATH variable.

shellscripts can't set paths, because it becomes a subshell. you need to source the script instead of executing it.

Kterm is actually running ~/.profile on startup, but isn't picking up on exports?

[NiLuJe]

IIRC, there's a login sell vs. non-login shell shenanigan for the KTerm thing (cf. KTerm's issue tracker on GH).