@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
.