Quote:
Originally Posted by NiLuJe
@DNSB: There's *never* an unpack to the FAT32 partition? There's no "copy" to the rootfs either.
There's a "copy" (i.e., a download by Nickel, OTA; or a manual copy by the user, via USBMS) of the KoboRoot tarball + upgrade folder to the FAT32 partition, then there's an unpack from there to the rootfs during the update process.
(Semantics, true, but that needed clarification not to confuse my point, which was solely about the actual unpack process to the rootfs, during which the state of the FAT32 partition is irrelevant, as nothing gets written to it  ).
EDIT: Okay, I was indeed glossing over a step in case of an OTA, assuming Nickel downloads the kobo-update ZIP first, actually stores it on disk, and then unpacks it, there's indeed an extra unpack to the FAT32 partition there, my bad .
I'm not familiar with the actual implementation, but it could just as well be "streaming" the unpack straight from memory, without needing the ZIP data to ever make it to disk.
Worth mentioning, but not the step I was concerned with . |
The pattern I've seen suggests the update.zip files is downloaded and unpacked (the two files and the upgrade directory) on disk -- if you tap update later, the .zip file is missing but the KoboRoot.tgz, manifest.md5sum and the upgrade directory are present in the .kobo directory. If the file does not unzip correctly, the update does not attempt to continue and an error message is written to the log file. Once that is done, limited testing suggests the files internal to the KoboRoot.tgz are extracted in memory and copied to the root partition. This suggests that as long as the root partition has enough free space for the largest file, the file copy from KoboRoot.tgz should not cause any issues.
Code:
nickel: ( 334.153 @ 0x179fa08 / ui.warning) void Unzipper::startWork() "/mnt/onboard/.kobo/updatefilename.zip" failed verify