Changes

Page history
Adjust for ikiwiki → GitLab wiki authored by intrigeri's avatar intrigeri
Show whitespace changes
Inline Side-by-side
Endless_upgrades.md
View page @ a5d53a93
[[!meta title="Endless upgrades"]]
---
title: Endless upgrades
---
Currently automatic upgrades have the limitation that only some N
number of them can be performed in a row before the system partition
......@@ -15,12 +18,14 @@ Automatic upgrades should be possible forever. This would:
number of times you might want to clone or rely on another operating
system for downloading or upgrading.
[[!toc levels=2]]
[[_TOC_]]
# Different approaches to endless upgrades
While examining these approaches, let's forget about IUKs for a while,
and only consider full automatic upgrades ([[!tails_ticket 7499]]):
and only consider full automatic upgrades (tails/tails#7499):
## Extract upgrade from ISO
......@@ -40,7 +45,7 @@ we reboot.
### Disk images instead of ISOs
Note that if we switch to using disk images as the primary way to
install Tails ([[!tails_ticket 8550]], comment 9) we can similarly
install Tails (tails/tails#8550, comment 9) we can similarly
extract the needed parts just like above: replace "(ISO|.iso)" with
"disk image" and it still works.
......@@ -74,7 +79,7 @@ the magic employed for the ISOBoot may hide too much about underlying
real device, which we still probably will need information about.
Some more details (some perhaps wrong) can be read in comment 16 on
[[!tails_ticket 7496]].
tails/tails#7496.
## Apply upgrade in initramfs
......@@ -97,7 +102,7 @@ security feature, but more a foolproof things, but why not?
## How others do i.e. non-NIH solutions
This survey will be updated in a while with [[!tails_ticket 15277]].
This survey will be updated in a while with tails/tails#15277.
* yocto project's
[comparison of system update mechanisms](https://wiki.yoctoproject.org/wiki/System_Update)
......@@ -115,7 +120,7 @@ This survey will be updated in a while with [[!tails_ticket 15277]].
a [RFC for casync support](https://github.com/rauc/rauc/pull/217)
which downloads only missing bits and downloads/applies with
streaming (no intermediate download of images)
- ITP: [[!debbug 916210]]
- ITP: [Debian bug #916210](https://bugs.debian.org/916210)
* [Qt's Over-The-Air Update](https://doc.qt.io/QtOTA/) aka. QtOTA,
that uses OSTree
* XXX: other OSTree based designs/implementations?
......@@ -132,7 +137,7 @@ This survey will be updated in a while with [[!tails_ticket 15277]].
- [file system and autoupdate system](https://www.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate)
- [Android's A/B System Updates](https://source.android.com/devices/tech/ota/ab_updates.html)
* [Endless ostree builder](https://github.com/cosimoc/deb-ostree-builder)
* [[!debbug 824649 desc=" ostree: document how to prepare and update a .deb-based system root"]]
* [ ostree: document how to prepare and update a .deb-based system root](https://bugs.debian.org/824649)
### Not suitable
......@@ -157,14 +162,14 @@ This survey will be updated in a while with [[!tails_ticket 15277]].
## Remove SYSLINUX from USB images: use GRUB for legacy boot
See [[!tails_ticket 17815]] for the rationale.
See tails/tails#17815 for the rationale.
Doing this move in isolation would have a very unfavorable cost/benefit, but if
revamping our image build & upgrade system lead us to rework in depth, or even
replace, most of the affected software components, it could be a good
opportunity to do this extra work.
And actually, some of the options for [[!tails_ticket 15277]] require
And actually, some of the options for tails/tails#15277 require
integration with bootloaders, and already support GRUB but not syslinux, so it's
possible we eventually _have to_ fully migrate USB images to GRUB.
......@@ -213,7 +218,7 @@ have a lot of time and/or a fast connection.
## Self-contained verification
An interesting option for Tails installation verification
([[!tails_ticket 7496]]) is to contain all the bits needed to verify
(tails/tails#7496) is to contain all the bits needed to verify
an installation's integrity. For instance, in the ISOBoot case we'd
include the .sig for the ISO on as well as the .iso, so an external
verifier simply can verify the .sig instead of needing an external
......@@ -234,8 +239,7 @@ integrity would be signed/verified at the same time as the ISO.
# Temporary stop gap: stack one single SquashFS diff when upgrading
(This idea was originally conceived in the comments of [[!tails_ticket
11131]].)
(This idea was originally conceived in the comments of tails/tails#11131.)
Without any major redesign of our current incremental upgrade system
(i.e. comparatively cheap) we can allow users upgrade only through
......@@ -322,7 +326,7 @@ The IUK size is involved in at least four concerns:
- While performing the upgrade, 2x the size of the IUK
of memory is needed, so 2*682 MB = 1364 MB. On a system with 2 GB of
memory, a fresh boot of Tails pre-4.0 devel branch, even with
[[!tails_ticket 12092]] fixed, has 900 MB of free memory
tails/tails#12092 fixed, has 900 MB of free memory
(according to `check_free_memory()`'s calculation in
`config/chroot_local-includes/usr/local/bin/tails-upgrade-frontend-wrapper`)
so the upgrade would fail.
......@@ -340,18 +344,18 @@ The IUK size is involved in at least four concerns:
amounts of RAM: they have to do a manual upgrade, which is probably
more painful, for most users, than 2 automatic upgrades.
- We can solve this regression by changing the format of the IUKs
([[!tails_ticket 6876]]); we should coordinate this with other changes
(tails/tails#6876); we should coordinate this with other changes
that will break automated upgrades from Tails N to N+1, such as
the migration to overlayfs ([[!tails_ticket 9373]]).
the migration to overlayfs (tails/tails#9373).
* Bandwidth needs of the RM. Uploading 10 GB of IUKs can be a pain for
some of us, but that can be solved by making it possible to
generate IUKs on lizard (and then compare them with the ones you
generated locally. Thanks reproducibility!): [[!tails_ticket 15297]].
generated locally. Thanks reproducibility!): tails/tails#15297.
## Support upgrading very old Tails
XXX: It seems that we do want to support skipping more than one Tails
release. See the discussion on [[!tails_ticket 17069]].
release. See the discussion on tails/tails#17069.
We probably do not want to support upgrading very old (e.g. from six
months ago) Tails installations because our signing key might have
......@@ -432,7 +436,7 @@ Total: 7853 MB
## Deployment
Assume we first ship in Tails version N~ the new Upgrader that supports
[[!tails_ticket 15281 desc="Endless automatic upgrades"]]. The initial
Endless automatic upgrades (tails/tails#15281). The initial
plan is N = 4.2.
When we release Tails version N:
......@@ -526,3 +530,4 @@ When we release Tails version N+1:
- If initial-install-version = N+1, the Upgrader fetches
`/upgrade/v2/Tails/N+1`, which says there is no upgrade available.