Kindle Voyage can't proceed past the initial "tree" screen

[njt]

Hello,

I recently purchased a kindle voyage from a secondhand shop. I was using Calibre and had a whole bunch of documents in the kindle that I just wanted to delete and start over, so I deleted everything in the documents folder, transferred content via Calibre (to the machine memory - or so it said). Deleted things from the kindle cloud and then took disconnected the kindle via the proper steps (Disconnecting the usb via the pc first, then unhooking the usb.)

Upon unhooking the usb it gave me an error saying I didn't disconnected it and it needs to fix. I got impatient after an hour and tried to reboot to have it get stuck at the tree screen.

I tried charging it until the light turned green restarting via long-pressing the power button and plugging it into the pc and all those steps to get it to work to no avail.

The Kubrick method appears to not work for the Kindle Voyage and from what I see, I can't add any files onto my kindle as it doesn't allow me to access its folders (it does show it is connected, and that is a kindle device - but nothing else)

Anyway, am I shit out of luck or is there some miracle solution?

Any help would be appreciated .

Thanks

[njt]

Ended up replacing - thanks anyway ^^;. (Thread can be dealt with as seen fit )

[knc1]

The Kindle's start-up code that rebuilds a corrupted filesystem scores very low on the IG (instant gratification) scale.

All you had to do was keep it powered and wait.

[NullNix]

Originally Posted by knc1

The Kindle's start-up code that rebuilds a corrupted filesystem scores very low on the IG (instant gratification) scale.

All you had to do was keep it powered and wait.

For more than an hour? What's it *doing* in there? Even resquashing an entire filesystem shouldn't take that long, and fsck is drastically faster even on spinning rust.

[HarryT]

Originally Posted by NullNix

For more than an hour? What's it *doing* in there? Even resquashing an entire filesystem shouldn't take that long, and fsck is drastically faster even on spinning rust.

It can take 24h, or even more!

[knc1]

Originally Posted by NullNix

For more than an hour? What's it *doing* in there? Even resquashing an entire filesystem shouldn't take that long, and fsck is drastically faster even on spinning rust.

Correcting the source of the error message you received.

Of course fsck is drastically faster on spinning rust, spinning rust is drastically faster than flash rom.

Keep in mind two things:
*) Flash storage (eeprom) can not be written to.
It can be read, it can be erased and it can be re-programmed, but write? Can't happen, the device's micro-controller is faking it.

*) Each time an error, either in the data recorded (in this case a file system) or in the underlying storage media, is encountered - -
**After** the device corrects itself internally, the whole fsck process has to be started again.

Let me guess your next question:

The reason you don't see this situation with the SSD in your (whatever) other device is because it is hidden by the controller inside of the device.
The micro-controller in an SSD is much more "intelligent" than that of an eMMC device.

Your attempts to re-start it and/or re-set it during the time it was initially dealing with the problem only made things worse, much worse.
But still, it would have recovered if kept on external power and left alone.

And yes, a day or two is reasonable for a 2G or 4G device.

And it **must** be on external power all of that time (the battery run-time of a Kindle is only 2 to 3 hours - not days).
Lose power to the eMMC device during one of its internal read-erase-merge-reprogram cycles and the device is ruined.

[NullNix]

Originally Posted by knc1

Correcting the source of the error message you received.

Of course fsck is drastically faster on spinning rust, spinning rust is drastically faster than flash rom.

Not so. fsck does relatively few writes -- it tries to keep the amount of change to a minimum, though the change will be scattered across eraseblocks and thus have a horrible write amplification. What it does is a *lot* of seeking, which is nearly instantaneous on flash.

*) Each time an error, either in the data recorded (in this case a file system) or in the underlying storage media, is encountered - -
**After** the device corrects itself internally, the whole fsck process has to be started again.

Oh god. If it's repeatedly rerunning fsck in the blind hope that maybe it'll work if it keeps trying enough, that might explain it.

The reason you don't see this situation with the SSD in your (whatever) other device is because it is hidden by the controller inside of the device.
The micro-controller in an SSD is much more "intelligent" than that of an eMMC device.

Good point. (Though I'm not the person who had the problem, I'm just a curious bystander who knows how e2fsck works.)

[knc1]

Originally Posted by NullNix

Not so. fsck does relatively few writes -- - - - - - -

But it **must** write to correct errors found.
It isn't magic.

And the flash 'write' (which it can't do, but must fake) is not the same effect of a hard drive with a bad sector that just sets an alternate sector (internally, in its controller).

The fact that fsck does not work in erase block chunks, erase block boundary aligned, is why it must start over.

There is no 'blindly' anything involved, its science, not magic.

[NullNix]

Originally Posted by knc1

But it **must** write to correct errors found.
It isn't magic.

What i meant is that it doesn't rewrite whole regions: it does occasional scattershot writes (though this will probably have to change at some point when it gains more support for SMR drives, because as with flash those have restrictions on how and where you can safely write).

And the flash 'write' (which it can't do, but must fake) is not the same effect of a hard drive with a bad sector that just sets an alternate sector (internally, in its controller).

Why do you claim it can't write to flash? Of course it can, but the modify write is *implemented* as an erase-and-new-write-and-pointer-update.

The fact that fsck does not work in erase block chunks, erase block boundary aligned, is why it must start over.

That's only true if it's fscking below the level of the flash translation layer, which is vanishingly unlikely. Fading memories tell me that this is ext3, not a flash filesystem, so there's a translation layer here, so fsck will be emitting writes just as if it were on spinning rust, and relying on the translation layers to remap these writes correspondingly. There is no support whatsoever in fsck for storage media where you do a write and it doesn't show up until you restart fsck (how would the translation layer even know fsck had terminated?!). If this isn't an ext*fs then my argument is nonsense because I'm talking about a completely different fsck program than is actually in use.

(However, I am presuming in the absence of the evidence here. I'm not even sure which filesystem's being rebuilt, hence my question. Presumably it's not the squashfs ones -- those are never modified, and it doesn't even *have* a pristine original copy of that if one *is* somehow messed up. So it must be the modifiable system partition, which is IIRC ext3, right?)

[knc1]

In the problem reported here, FAT32.

And you just explained why fsck has to start over, re-read your own post.