mariatuplayground/ Trebuchet/ tb-update

Trebuchet Update

Trebuchet update takes care of deploying a tbdiff update image in the background on a production system while it is running. Its workflow should work as follows:

  • Create a snapshot of the current root filesystem subvolume (snapshots/current -> snapshots/new)
  • Deploy the update image to snapshots/new
  • Move snapshots/current to snapshots/previous
  • Move snapshots/new to snapshots/$UUID and snapshots/current
  • Copy snapshots/$UUID to snapshots/root
  • Set snapshots/root as default subvolume (this will make such subvolume the default one at mount time)
  • Deploy kernel updates in the boot partition (/boot needs to be ext2,3,4 in x86 and ARM/Linaro/u-boot needs flash-kernel to be run)
  • Reboot

Once we put in place a smarter bootloader for tb-update we should check if the filesystem booted correctly, and if not, rollback to snapshots/previous.

Code

The repository can be found in https://gitorious.org/baserock/tb-update

Filesystem layout

For tb-update to work we need the following prerequisites:

  • A system running a BtrFS (or equivalent copy-on-write snapshot capable FS such as ZFS) root filesystem
  • User data (content and user installed apps) should not be in the root BtrFS subvolume
  • Writeable directories should not be in the root file s / /home /var/log /tmp /root and other writeable
  • The / filesystem should be snapshots/root (the 0 id subvolume is not usable due to a bug in BtrFS wrt set-default)
  • The convention is that the current root filesystem should be the snapshot named "snapshots/root"
  • A read only subvolume of the root file system should be in snapshots/current and a read only copy of the previous one in snapshots/previous
  • / (specially /etc) should not be writeable, no configuration performed by a user should affect the root file system

Known issues in BtrFS

  • Once you set-default a subvolume id other than 0 (the original one), you cannot set it back to 0, you can however, set it to any other subvolume. This means that during system setup, we need to install everything in snapshots/root
  • subvolumes cannot be mounted in arbitrary places (like /home), we need to fix this to avoid updating user data on the initial prototypes
  • There's no way to generate an image of differences between subvolumes that are part of a common history. Eventually we should generate a tbdiff compatible image once the format is stable and use this to implement the ZFS send/receive counterpart.

TODO

  • The current tb-update tool relies on a .tar.gz implementation of the update delivery format. Since tbdiff is close to finished, tp-update should be updated to use tbdiff-deploy
  • Client daemon: We need a client daemon that pokes the update server for new updates or rollback commands.
  • Server side: We need to develop a web service with a frontend to demonstrate easy update deployments