3 ms·
Sure it is quite inefficient. Both in storage and in transmission of updates. But it is very simple and robust. What one tests pre rollout is identical to what
by jononor 9y ago
Sure it is quite inefficient. Both in storage and in transmission of updates.
But it is very simple and robust. What one tests pre rollout is identical to what will go on production devices, down to the byte. Each device with same version is identical. It can be cryptographically verified easily. Automatic rollback can be performed on update fail, including self-checks.
This approach of shipping a custom userland without any of the generic Linux userland should drastically bring down the size.
- secure 9y agoI strongly agree regarding the simplicity! A minimal gokrazy root file system is 16MB in size. On a 8GB SD card, I certainly am willing to sacrifice another 16MB to get A/B updates :).
- dividuum 9y agoTransmission of updates can be quite small: For the info-beamer hosted (https://info-beamer.com/hosted https://info-beamer.com/hosted) OS, we also do A/B booting. Updates are implemented using zsync. The initial installation of the OS is simply done by unzipping a carefully crafted [1] install.zip file to the Raspberry Pi SD card. By exploiting zsync features, it's quite efficient to reconstruct the original install.zip from the unpacked files. Once that's done, all future updates also use zsync and only fetch changes to the locally stored 'install.zip' file. After updating this file we then unpacked everything again to the next A/B partition, so the exact state of the system is always known. Updates are quite small that way. It also helps that the complete OS is only ~37MB compressed at the moment. [1] The root file system is squashfs and is stored uncompressed in the zip file to avoid double compression and allows zsync to use the squashfs blocksize to find a minimal set of changes. Similarly the initramfs.gz is compressed --rsyncable and also also stored uncompressed in the zip file.