Closed leigh-johnson closed 1 year ago
Digging into this one today! I just realized that swu patching should be zero-copy, indicated by the installed-directly = true;
setting in the root filesystem description. So the fact that updates are being saved to a file and then applied is a bug, or the installed-directly
setting isn't being applied.
From swupdate docs:
* reads through the cpio archive one file at a time and either:
** execute handlers for each file marked as "installed-directly". checksum is checked while the data is streamed to handler, and copy will be marked as having failed if checksum was not correct failing the rest of the install.
** copy other files to a temporary location while checking checksums, stopping if there was a mismatch.
https://github.com/sbabic/swupdate/blob/master/doc/source/swupdate.rst#running-swupdate
Looks like nginx is responsible for buffering the file to /var/run/nginx instead of streaming the bytes over to the mongoose server. 👀
Jan 05 09:28:21 pn-v0-5 nginx[688]: 2023/01/05 09:28:21 [warn] 688#688: *4 a client request body is buffered to a temporary file /run/nginx/client_body_temp/0000000001, >
:tada: WOO, swupdate patching is now zero-copy.
To recap how this works:
[extract_files] : Installing STREAM printnanny-release-image-raspberrypi4-64.ext4.gz, 756257029 bytes
Describe the bug
Right now, .swu files are downloaded to
/run
which is a volatile memorytmpfs
. If the Pi is under even a moderate amount of memory pressure, the 700mb+ .swu file will fail to download. We should download this file to a persistent path under/data
and rotate old images.