PW4 Some notes on PW4 issues and resolution

fllc · 07-19-2019, 03:06 PM

Just got a new PW4 on Prime day: 8gb, SO, wifi, 5.10.1.3.

I wanted to avoid 5.12 so decided to JB and upgrade to 5.11.2. (My old PW4 is 5.10.3. JB and everything...)

Downloaded everything from the latest snapshots.
Skipped wifi config and registration, and proceeded with JB.

*** I did not put it in airplane mode ***

JB went fine. Upgraded to 5.11.2. Installed MRPI, KUAL, usbnet, gawk, librariansync, python, linkss and a bunch of other extensions. Basically, set up this PW4 identically to my old PW4.

Copied my dictionaries and a collection of books. So now the 2 PW4 are identical in content. The main diff is that the old PW4 had all packages from snapshots as of early March.

Generated collections from folders. Setup SS to cover mode. Rebooted. Did a quick check and noticed that the PW4 was sluggish on all touches and page turns. Also, the message that SS Cover mode did not process any covers yet. Left the PW4 on wall charger and went to dinner.

Came back a couple of hours later and see that nothing improved. Cover mode is still giving message. Page turns are slow. And indexing only processed less than 10 books per hour. No matter what books I opened (mobi, azw3, User Guide) could not get the cover mode to work, and still sluggish.

Deleted all books except 1 and User Guide. Let it index 1 book. No change.

Uninstalled Python and linkss from current snapshot and reinstalled Python and linkss from the March snapshot. No change: no cover mode and sluggish.

Knowing that occasionally Amazon updates impact device performance, I thought that maybe 5.10.1.3 to 5.11.2 update did something. So I ran the hotfix, reset the device, reinstalled and recopied everything. No change: no cover mode and sluggish, and very slow indexing.

At this point I knew that I need help from the guru, and decided to prepare a set of logs that NiLuJe will request: ran ;DM, collected MRPI log, ran SS in verbose mode. Before asking for help I started reading the logs. There were no problems with any packages. However, there was a barrage of errors in System log that it's trying to connect to network and failing everything (sync, store, metadata, authentication, blah-blah-blah). But I never even connected to wifi!

*** So I put the device into airplane mode! ***

Suddenly, there is no sluggishness, indexing is working as expected, cover mode is working!

So even if you never configure wifi and never connect to anything, airplane mode is absolutely necessary.

mergen3107 · 07-19-2019, 03:35 PM

What if you put an empty extensionless file SKIP_UPDATE_CHECK into /var/local/system/ ?
Will it try to look for updates anyway?

NiLuJe · 07-19-2019, 03:51 PM

Note that the "Prevent OTA updates" button in the Helper extension does just that, so it may help.

It will NOT on 5.12, as this one appears to have taken the bull by the horns and decided to workaround the issue by forcefully removing the block folder and stop supporting SKIP_UPDATE_CHECK

.

dhdurgee · 07-19-2019, 03:55 PM

Quote:

Originally Posted by NiLuJe

Note that the "Prevent OTA updates" button in the Helper extension does just that, so it may help.

It will NOT on 5.12, as this one appears to have taken the bull by the horns and decided to workaround the issue by forcefully removing the block folder and stop supporting SKIP_UPDATE_CHECK

.

Joy. So the only way to stop updates with 5.12 or future releases will be airplane mode and doing everything via USB attachment. That is indeed evil.

Dave

hius07 · 07-19-2019, 04:14 PM

Quote:

Originally Posted by NiLuJe

It will NOT on 5.12, as this one appears to have taken the bull by the horns and decided to workaround the issue by forcefully removing the block folder and stop supporting SKIP_UPDATE_CHECK

.

Sorry, I missed the message reporting about the removing the block folder on 5.12.1.
Can you please give the link.

fllc · 07-19-2019, 05:04 PM

I did "Prevent OTA updates" via KUAL as soon as I installed KUAL! So, no, it did not change the constant attempts to connect!

mergen3107 · 07-19-2019, 05:10 PM

@fllc, OK!
I only wonder why did it take Amazon so many FW updates to teach them to remove this folder?

A wild guess is that indeed their FW architecture does not allow even them to downgrade, so they left this backdoor as a safety measure or something.

Which leads me to conclusion that probably they are revising the downgrade/upgrade mechanisms.

j.p.s · 07-19-2019, 05:13 PM

Quote:

Originally Posted by mergen3107

@fllc, OK!
I only wonder why did it take Amazon so many FW updates to teach them to remove this folder?

A wild guess is that indeed their FW architecture does not allow even them to downgrade, so they left this backdoor as a safety measure or something.

Which leads me to conclusion that probably they are revising the downgrade/upgrade mechanisms.

The update blocker never enabled downgrading, so that is not it.

j.p.s · 07-19-2019, 05:20 PM

Quote:

Originally Posted by NiLuJe

Note that the "Prevent OTA updates" button in the Helper extension does just that, so it may help.

It will NOT on 5.12, as this one appears to have taken the bull by the horns and decided to workaround the issue by forcefully removing the block folder and stop supporting SKIP_UPDATE_CHECK

.

So, the equivalent of rm -rf

I would have thought their lawyers would at least be a teeny bit nervous about the possibility of deleting import user generated files.

NiLuJe · 07-19-2019, 05:42 PM

@hius07: https://www.mobileread.com/forums/sh...&postcount=477 & https://www.mobileread.com/forums/sh...1&postcount=80

@j.p.s: You don't even know how right you are ;D. It's indeed a hardcoded rm -rf system() call

.

All of that is in one of the ota* *binaries*, I can't remember the exact one OTOH, probably otaupv3 or something.

You'll need a < 5.12 version to compare to, of course

.

NiLuJe · 07-19-2019, 05:45 PM

They do have a downgrade mechanism in place. At least in the FW. I assume there's a similar knob in the initrd updater, with a bit of luck possibly the exact same one. Too lazy to check

.

trcm · 07-22-2019, 02:07 PM

If update.bin.tmp.partial has been nix'd, is there another prevention mechanism available?

Blackholing their update servers in /etc/hosts ?

knc1 · 07-22-2019, 02:40 PM

Quote:

Originally Posted by trcm

If update.bin.tmp.partial has been nix'd, is there another prevention mechanism available?

Blackholing their update servers in /etc/hosts ?

Airplane mode or a different e-reader brand.
Right! I am getting a little bit pissed at this vendor.

-------

I think I will play with quad-copters for a pass-time.
Those usually run Linux (both on the flight control system, and the on-ground controller).

NiLuJe · 07-22-2019, 02:43 PM

I suspect blackholing might revive the "let's stupidly retry indefinitely" issues and the accompanying CPU drain...

Plus, as @knc1 can attest to, pinpointing every Amazon server under the sun and what they're used for is easier said than done...

.

trcm · 07-22-2019, 02:45 PM

Does the file system support ACLs, any immutable flag that could be applied?

07-19-2019, 03:06 PM	#1
fllc has been Posts: 55 Karma: 765322 Join Date: Feb 2015 Device: k2, k4nt, touch, PW2, koa2, pw4, Nook GLP 7.8	Some notes on PW4 issues and resolution Just got a new PW4 on Prime day: 8gb, SO, wifi, 5.10.1.3. I wanted to avoid 5.12 so decided to JB and upgrade to 5.11.2. (My old PW4 is 5.10.3. JB and everything...) Downloaded everything from the latest snapshots. Skipped wifi config and registration, and proceeded with JB. * I did not put it in airplane mode * JB went fine. Upgraded to 5.11.2. Installed MRPI, KUAL, usbnet, gawk, librariansync, python, linkss and a bunch of other extensions. Basically, set up this PW4 identically to my old PW4. Copied my dictionaries and a collection of books. So now the 2 PW4 are identical in content. The main diff is that the old PW4 had all packages from snapshots as of early March. Generated collections from folders. Setup SS to cover mode. Rebooted. Did a quick check and noticed that the PW4 was sluggish on all touches and page turns. Also, the message that SS Cover mode did not process any covers yet. Left the PW4 on wall charger and went to dinner. Came back a couple of hours later and see that nothing improved. Cover mode is still giving message. Page turns are slow. And indexing only processed less than 10 books per hour. No matter what books I opened (mobi, azw3, User Guide) could not get the cover mode to work, and still sluggish. Deleted all books except 1 and User Guide. Let it index 1 book. No change. Uninstalled Python and linkss from current snapshot and reinstalled Python and linkss from the March snapshot. No change: no cover mode and sluggish. Knowing that occasionally Amazon updates impact device performance, I thought that maybe 5.10.1.3 to 5.11.2 update did something. So I ran the hotfix, reset the device, reinstalled and recopied everything. No change: no cover mode and sluggish, and very slow indexing. At this point I knew that I need help from the guru, and decided to prepare a set of logs that NiLuJe will request: ran ;DM, collected MRPI log, ran SS in verbose mode. Before asking for help I started reading the logs. There were no problems with any packages. However, there was a barrage of errors in System log that it's trying to connect to network and failing everything (sync, store, metadata, authentication, blah-blah-blah). But I never even connected to wifi! * So I put the device into airplane mode! * Suddenly, there is no sluggishness, indexing is working as expected, cover mode is working! So even if you never configure wifi and never connect to anything, airplane mode is absolutely necessary.

07-19-2019, 05:42 PM	#10
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@hius07: https://www.mobileread.com/forums/sh...&postcount=477 & https://www.mobileread.com/forums/sh...1&postcount=80 @j.p.s: You don't even know how right you are ;D. It's indeed a hardcoded rm -rf system() call . All of that is in one of the ota* binaries, I can't remember the exact one OTOH, probably otaupv3 or something. You'll need a < 5.12 version to compare to, of course . Last edited by NiLuJe; 07-19-2019 at 05:47 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PW4 Charging....	patrickt	Amazon Kindle	2	05-09-2019 05:07 PM
Troubleshooting PW4	Barbara1955	Amazon Kindle	22	12-23-2018 06:56 PM
Placeholder for PW4 jailbreaking notes - reminder - DO NOT UPDATE	coplate	Kindle Developer's Corner	12	11-09-2018 10:11 AM
Issues taking notes - firmware or touchscreen issue? - Kobo Glo HD	biojack	Kobo Reader	8	04-07-2016 10:23 PM
PW4 ?	Scarpad	Amazon Kindle	5	11-29-2015 04:51 PM

07-19-2019, 03:35 PM	#2
mergen3107 Wizard Posts: 1,506 Karma: 5000046 Join Date: Feb 2012 Location: Cape Canaveral Device: Kindle Scribe	What if you put an empty extensionless file SKIP_UPDATE_CHECK into /var/local/system/ ? Will it try to look for updates anyway?

07-19-2019, 03:51 PM	#3
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Note that the "Prevent OTA updates" button in the Helper extension does just that, so it may help. It will NOT on 5.12, as this one appears to have taken the bull by the horns and decided to workaround the issue by forcefully removing the block folder and stop supporting SKIP_UPDATE_CHECK .

07-19-2019, 05:04 PM	#6
fllc has been Posts: 55 Karma: 765322 Join Date: Feb 2015 Device: k2, k4nt, touch, PW2, koa2, pw4, Nook GLP 7.8	I did "Prevent OTA updates" via KUAL as soon as I installed KUAL! So, no, it did not change the constant attempts to connect!

07-19-2019, 05:10 PM	#7
mergen3107 Wizard Posts: 1,506 Karma: 5000046 Join Date: Feb 2012 Location: Cape Canaveral Device: Kindle Scribe	@fllc, OK! I only wonder why did it take Amazon so many FW updates to teach them to remove this folder? A wild guess is that indeed their FW architecture does not allow even them to downgrade, so they left this backdoor as a safety measure or something. Which leads me to conclusion that probably they are revising the downgrade/upgrade mechanisms.

07-19-2019, 05:45 PM	#11
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	They do have a downgrade mechanism in place. At least in the FW. I assume there's a similar knob in the initrd updater, with a bit of luck possibly the exact same one. Too lazy to check .

07-22-2019, 02:07 PM	#12
trcm Connoisseur Posts: 96 Karma: 100000 Join Date: Dec 2018 Location: London Device: Kobo Libra H2O	If update.bin.tmp.partial has been nix'd, is there another prevention mechanism available? Blackholing their update servers in /etc/hosts ?

07-22-2019, 02:43 PM	#14
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	I suspect blackholing might revive the "let's stupidly retry indefinitely" issues and the accompanying CPU drain... Plus, as @knc1 can attest to, pinpointing every Amazon server under the sun and what they're used for is easier said than done... .

07-22-2019, 02:45 PM	#15
trcm Connoisseur Posts: 96 Karma: 100000 Join Date: Dec 2018 Location: London Device: Kobo Libra H2O	Does the file system support ACLs, any immutable flag that could be applied?