Tools Snapshots of NiLuJe's hacks

[j.p.s]

Originally Posted by NiLuJe

Small update, mainly with a KUAL update so that the Booklet version properly updates its atime on exit (meaning it behaves like the old Kindlet variant, getting properly sorted by "Recent" depending on when you last launched it).

(Sorry @j.p.s ).

I was going to ask whether it would be possible to do this.

[j.p.s]

Originally Posted by NiLuJe

Small update, mainly with a KUAL update so that the Booklet version properly updates its atime on exit (meaning it behaves like the old Kindlet variant, getting properly sorted by "Recent" depending on when you last launched it).

(Sorry @j.p.s ).

Will this work with KOA2 (and PW4), or is coplate's patched version required?

Or does this update need to be incorporated into coplate's version?

[NiLuJe]

I keep both versions in sync . So as long as the method is found, it should work. Check KUAL's log if something looks wrong, it'll log the fact that the sigscan failed.

I only tested the "vanilla" Booklet, as my PW2 is still running 5.9.7, so I don't need the patched variant .

[j.p.s]

After several hours of searching and reading, I can not figure out whether it is required to uninstall KUALBooklet before updating to a new version.

[NiLuJe]

@j.p.s: Nope .

It might require a framework restart to defeat weird Java caching in order to properly pickup the new version, but MRPI should be doing that already, so that only applies to ninjas who might be trying to install it manually .

(Generally, if there's no uninstaller, it's either because you never need to bother about it, or because it's trivial enough to do).

[j.p.s]

Originally Posted by NiLuJe

@j.p.s: Nope .

It might require a framework restart to defeat weird Java caching in order to properly pickup the new version, but MRPI should be doing that already, so that only applies to ninjas who might be trying to install it manually .

(Generally, if there's no uninstaller, it's either because you never need to bother about it, or because it's trivial enough to do).

Thanks.

The thing is, there are Update_KUALBooklet_*_uninstall.bin

I was hoping they are just for cleanup for complete removal, but could not find anything about it.

In any case, I did the update without uninstall on my KOA2 and it worked fine. I even took the plunge and did the update inside KUAL.

[NiLuJe]

@j.p.s: Yep, it's to undo the appreg db changes .

(But the install script is designed to handle the db update sanely, it's not going to do anything stupid if the changes are already implemented).

[knc1]

Originally Posted by j.p.s

Thanks.

The thing is, there are Update_KUALBooklet_*_uninstall.bin

I was hoping they are just for cleanup for complete removal, but could not find anything about it.

In any case, I did the update without uninstall on my KOA2 and it worked fine. I even took the plunge and did the update inside KUAL.

Hint:
You can un-package it with kindletool.
And in this case (both the install and the uninstall) are human readable scripted sql commands.

[mergen3107]

I read in few places here on forum about rescue packs.

Can you guys please clarify this once again: when exactly should I install them?
For example, I have PW3 on 5.9.7 right now, with JB. I only fiddled around with margins and screensavers.
Should install rescue packs before installing 5.10.2 manually?

Also, one related question － if I leave "SSH at boot" in USBNetwork will it help me to unbrick Kindle if it stuck on boot loop after the update?

[NiLuJe]

@mergen3107:

If you intend to work on JARs or upstart services that *may* throw you into a boot loop (or if you just like the safety net), and are okay with working over SSH in diags, then basically, yes, ASAP (ideally, after having familiarized yourself with how USBNet works ).

You'll generally always want RP+CRP together.

And while RP does some persistent changes to the diags partition, the "trigger" bit is like any other hacks, it will get wiped by a FW update.

(As for your SSH at boot question: it depends. It may help with *some* type of boot loops, *if* you're quick enough, but not for others. While RP+CRP should be able to get you out of more potential pickles ).

[mergen3107]

I see. Thank you so much!

[Antinoos]

BTW: In the latest mrinstaller.sh seems to be a problem with the new implementation for differentiation between "PW2" and "K5" machine architecture. On my KT3, the binary tarball for "PW2" was installed instead of the correct "K5". Had to correct this manually by unpacking the K5 tarball.

[NiLuJe]

That's actually a very old bug having been fixed. The KT3 really should prefer PW2 (i.e., A9) binaries .

It already does everywhere else (hence the split between touch/pw1 and everything else for the packages).

[Antinoos]

Thanks for this piece of info. Didn't know that, as the differentiation between internally named "PW2" binaries for the backlit PW models and another family named "K5" for Kindles with the old 167 ppi display (even the 9th generation KT3) really did sound reasonable.

BTW: What are the side effects running wrong kindletool and libz in everyday''s usage? Didn't notice any problems over more than 2 years using my jailbroken KT3 with the "wrong" binaries in MRPI installation?

[NiLuJe]

None, the PW2 binaries are just targeting a slightly newer system/CPU, which should hopefully make them infinitesimally faster. More importantly (for me ;p), it makes some stuff less of a hassle to cross-compile.

(i.e., you can run K5 binaries on a PW2+, but you can't run PW2 binaries on a Touch [well, you might be able to, but that's blind luck ]).