K5 Backing Kindle Touch up before upgrading firmware

[vedg]

Because of lack of suggestions to fix Kindle Touch slowdown, I decided to upgrade firmware to the latest official Amazon version. First I'll upgrade from 5.1.2 to 5.3.2.1. If this doesn't help, I'll upgrade further to 5.3.7.3.

I'd like to have an option to downgrade back to 5.1.2 if the upgrade causes more issues than it solves. How can I back up my Kindle? I have read A: The easy way section here: https://wiki.mobileread.com/wiki/Kin...Hacking#Backup. The SSH-enabled diags partition instructions README.txt file download link is broken. The even simpler way using Kubrick seems to refer to flashing firmware without prior backing up. So is Kubrick an easy and reliable way to revert to an earlier firmware version, which eliminates the need of system backup? Or is it still safer and recommended to make a system backup beforehand? If yes, does anyone have the now-undownloadable README.txt file with instructions? Or is there a newer, easier way not mentioned in the Wiki? For example this backup script was tested on KT firmware 5.3.7.3, so I'm not sure it will work on my old firmware version; plus the instructions seem to assume already working USB networking, which I don't have yet.

My computer system is GNU/Linux (in case this makes a difference).

[knc1]

Originally Posted by vedg

- - - -

For example this backup script was tested on KT firmware 5.3.7.3, so I'm not sure it will work on my old firmware version; plus the instructions seem to assume already working USB networking, which I don't have yet.

My computer system is GNU/Linux (in case this makes a difference).

Q: Does your Kindle have a touch screen?
A-Yes: It will work.
A-No: It will not work.


You do not need USB network specifically, only a way to enter the command to call the script.
I.E: KTerm, TelNet, or use the ability to call a custom script from the search bar.



Hmm...
The thread of search bar custom scripts may already have a worked example.

[NiLuJe]

Note that if you're mainly reading PDF document, @jonvarteresian recently figured out that there was a resource leak in the PDF reader, which could translate to degraded performance over time.

(And that was on a much newer device, with recent FW, so a FW update potentially won't help ).

[vedg]

I haven't read PDF on my Kindle for a long time. AZW3 is the most convenient format for me.

@knc1, I might try your backup script. However I can't find an easy way to restore the system from such a backup.

What is the benefit of backing up, then restoring manually over simply reverting the firmware to 5.1.2 with Kubrick? I can think of two possible answers to this question:
a) the manual way allows to preserve all the installed modifications and preferences;
b) Kubrick restoration may fail, while manual restoration is more reliable;
c) something else?

[knc1]

Originally Posted by vedg

- - - -

@knc1, I might try your backup script. However I can't find an easy way to restore the system from such a backup.
- - - -

Duh...
On your Linux PC, type:
man cp


Or read the 'restore' portion of our manual de-bricking guides.

[vedg]

I've just created a complete system's backup of my Kindle with the script.

If I understand correctly, there are no straightforward instructions for complete system recovery from the backup. A script user has to decide on his own which files to restore.
I've read Original "Simple" debricking methods for K5-Touch, K4-Mini, & K3-Keyboard and have a few questions regarding non-bricked Kindle system recovery (firmware downgrade):
(I) Can the recovery/downgrade be done in normal, non-fastboot mode if USB networking works with the new firmware?
(II) Will the following simple restoration process work?

1. Extract the backups archive into visible USB storage.
2. Swap dd's if and of arguments in mkbackup.sh's commands that create *.bin files; replace "skip" with "seek" in the first 3 dd commands; execute the modified dd commands for all backups/*.bin files.
3. Restore /proc/config.gz by swapping cp's SOURCE and DEST arguments.

[NiLuJe]

With the caveat that you can only restore main from diags, and diags from main, and you *must* match the kernels properly (diags w/ diags, main w/ main, version matched).

Also, /proc is not a real physical FS, don't touch it.

[vedg]

So a complete restoration plan could be:

1. Boot into diags mode; restore mainkern.bin and mainsys.bin with dd.
2. Boot into main mode; restore diagkern.bin and diagsys.bin with dd.

Questions:

1. When to restore prefix.bin? (complete /dev/mmcblk0 partitioned area prefix)
2. When to restore localsys.bin?
3. How to restore /proc/config.gz if not by copying it back? If it can't be restored, why mkbackup.sh backs it up?

[NiLuJe]

Don't, those are purely for informational / tinkering purposes (and/or when you really really mess up).

[vedg]

Originally Posted by NiLuJe

Don't, those are purely for informational / tinkering purposes (and/or when you really really mess up).

Do you mean that none of prefix.bin, localsys.bin and /proc/config.gz should be restored?

The Wiki says that deleting the /var/local partition's contents results in losing settings. It makes me think that restoring localsys.bin can be useful.

[NiLuJe]

If you change FW version, any or all of the settings might actually be expecting a different format, and FW do NOT have sane downgrade paths for those (hell, the upgrade paths are sometimes iffy, too).

Which is why we recommend *wiping* /var/local when downgrading.

On the other hand, if you don't touch /var/local, you don't have to restore it, either.

None of those settings are critical if you're using a real account (f.g., a factory reset wipes /var/local, among other things).

Note that we *do* use /var/local for JB restoration purposes, so, if you do wipe it, you'll have to be careful in which order you do things if you don't have a sane diags as a rescue...

[vedg]

I've made a complete backup with my current firmware version. Next I plan to upgrade to a new firmware version. Then I might want to get back to the firmware and settings I have now. In that case I suppose I can simply dd everything from the backup to downgrade as outlined in my complete restoration plan above. So /var/local from backup will match the firmware version from the same backup unless I misunderstand something.

If restoring localsys.bin makes sense, a question remains: when is it safer to do this - in the first step from the diags mode or in the second step from the main mode?

[NiLuJe]

Probably when you're restoring main from diags. I don't recall if diags actually uses varlocal, but if it does, it might be a bit trickier.