summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTails developers <amnesia@boum.org>2011-06-10 00:13:53 +0200
committerTails developers <amnesia@boum.org>2011-06-10 00:13:53 +0200
commit419cf25c9dde495c79ddcc3a6137397f230d8642 (patch)
treeba83d824faa2cec60237ba8cc768456f6e6f7c68
parent52724b8b6d74995423b6150113650fb58cda64a9 (diff)
Add some thoughts about a possible upgrade system
-rw-r--r--wiki/src/todo/usb_install_and_upgrade.mdwn95
1 files changed, 95 insertions, 0 deletions
diff --git a/wiki/src/todo/usb_install_and_upgrade.mdwn b/wiki/src/todo/usb_install_and_upgrade.mdwn
index 500d775..39d0830 100644
--- a/wiki/src/todo/usb_install_and_upgrade.mdwn
+++ b/wiki/src/todo/usb_install_and_upgrade.mdwn
@@ -404,3 +404,98 @@ D-Bus interface that makes it easy to programmatically partition a
storage device and create filesystems in there without messing with
low-level details; its LUKS encryption support probably is the killer
feature that makes it the perfect library for the job.
+
+Upgrade
+-------
+
+The upgrade issue is actually twofold: network burden and writing the upgraded
+live system on the USB stick.
+
+### Full CD image
+
+Can a memory stick be upgraded using the full CD image distributed for the new
+Tails version?
+
+A full CD image (700 MiB) is a lot of data to download. If done over Tor this
+is a pretty heavy load for the network and takes a fair amount of time.
+
+To support upgrade in a running system:
+
+ * 700 MiB of RAM would need to be available to store the downloaded image.
+ * The USB stick must be able to store two different images (either `squashfs`
+ or full ISO, depending on the chosen boot method). Otherwise the system
+ is likely to crash if the currently running *squashfs* disappears.
+
+### Partial download
+
+To reduce the previous requirements, Tails would need to provide only what
+has changed between two releases (deltas) and have a way to apply those changes
+to the previous version.
+
+#### Alreday existing tools
+
+Plain `diff` does not work on binary files.
+
+Binary diffs ([rsync], [xdelta], [bsdiff], [VCDIFF]) gives poor
+result on live system images because `squashfs` images vary
+strongly as a whole, even for tiny changes of the files inside.
+That situation is unlikely to change ([[!debbug 602965]]) and is even worse
+with `squashfs-lzma`. Quoting `xz` manpage:
+
+ Compressed output may vary
+ The exact compressed output produced from the same uncompressed input
+ file may vary between XZ Utils versions even if compression options
+ are identical. This is because the encoder can be improved (faster or
+ better compression) without affecting the file format. The output can
+ vary even between different builds of the same XZ Utils version, if
+ different build options are used.
+
+ The above means that implementing --rsyncable to create rsyncable .xz
+ files is not going to happen without freezing a part of the encoder
+ implementation, which can then be used with --rsyncable.
+
+[xdelta]: http://xdelta.org/
+[bsdiff]: http://www.daemonology.net/bsdiff/
+[VCDIFF]: http://www.ietf.org/rfc/rfc3284.txt
+
+#### Appending to `squashfs` image
+
+`mksquashfs` can actually append new files to an existing `squashfs` image.
+
+Initial images are created with files in a specific order to
+[[improve boot time on cd]], but on a USB stick random access in a non-issue.
+
+[[!taglink todo/test]] if `mksquashfs` can append an image that is currently
+used without weakening a running system.
+
+[[!taglink todo/research]] if it possible to "remove" files with appended
+images.
+
+Upgrading the system would result in a series of files to be appended to the
+current `squashfs` image.
+
+#### Stacking `squashfs` images
+
+Tails filesystem is already using `aufs` to provide a read-write filesystem on
+top of the read-only `squashfs` image.
+
+This system could probably be extended to support mounting multiple `squashfs`
+filesystems on top of each others. Upgrades would be `squashfs` images with
+only the files that have been modified since the previous releases.
+
+Yet again, there is need to [[!taglink todo/research]] how to handle deletions.
+
+Shipping upgrades could be as simple as shipping those extra `squashfs` images.
+
+#### Deltas
+
+A possible way to encode deltas for the two previous methods could be:
+
+ * For each file that has been modified: a binary delta and a new set of
+ metadata if they have changed.
+ * A list of deleted files.
+
+And `mksquashfs` would be used in the running live system after applying the
+delta to create a `squashfs` image with the upgrade.
+
+But there is probably things that have been left out of such an early draft.