Quote:
Originally Posted by geekmaster
I do not know if it would help you, but my "universal" mntus.params payload handles the "usb drive not mounted" problem by mounting /mnt/us itself before calling RUNME.sh.
|
Thanks for the hint, but no... it's already too late at the point where the framework is started. Remember, this only applies if the Kindle is starting up while being connected to a computer as a USB drive. Then, the system actually reports the file system as
mounted, but it's simply empty. As soon as the user unplugs/ejects the drive from the computer, files appear. I don't know how exactly they solved this, but it makes perfect sense: it is a
very bad idea to access the same filesystem concurrently (especially with FAT, which is pretty fragile anyway).
I saw only two solutions to access the patches directly from the userstore:
1. block until files become available. This works, in principle. But a) the startup will simply hang until the user ejects the drive, and b) if that takes too long (>60 seconds or so), the device will actually reboot because it (rightfully) determined that the framework did not start up.
2. Find a way to forcefully eject the drive. Again, a) I don't know how to reliably do this, and b) worse, this might make it impossible to debrick a device.
This is why I went for the "shadow copy" solution. Note that it is really only relevant if the first boot directly after the installation happens with the Kindle attached to the computer. In all other cases, jbpatch will have had a chance to synchronize the files before it starts up.
And of course, it's all documented (not technically, but describing for laymen "what to do"), both in the README, and the CONFIG.TXT
