| Summary: | Updater: Make a filesystem suitable for the Stefano Updater | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Other YP Layers | Reporter: | Mariano Lopez <mariano.lopez> |
| Component: | layers | Assignee: | Unassigned <unassigned> |
| Status: | RESOLVED OBSOLETE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | bluelightning, poky.bs.watcher, poky.watcher, richard.purdie, sbabic |
| Version: | unspecified | ||
| Target Milestone: | Future | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
| Bug Depends on: | |||
| Bug Blocks: | 8797 | ||
|
Description
Mariano Lopez
2015-07-14 22:06:27 UTC
There are ways in swupdate to save and restore "configuration", but there is no a single way to do. In most cases, it is required to save databases and maybe to have a database migration from a version to the next one. As well, some other data must survive to the update. I get different meaning about "configuration" according and each project has its sight. The way this is done is generally specific to a project. In some case, a separate partition or UBI volume is used as "data", in other cases the old configuration (network configuration, ..) is saved and restored. This is done by using the pre- and postinstall feature of swupdate. A swupdate image contains scripts that allow a migration of data from a version to the next one. At the moment, a general case to save data is foreseen if data are saved into a UBI volume and volumes must be repartitioned. In this case, data are saved and restored after repartitioning. (In reply to comment #1) > There are ways in swupdate to save and restore "configuration", but there is > no a single way to do. In most cases, it is required to save databases and > maybe to have a database migration from a version to the next one. As well, > some other data must survive to the update. I get different meaning about > "configuration" according and each project has its sight. I agree with you on this, it depends on the project what should be saved and what should be overwritten. > > The way this is done is generally specific to a project. In some case, a > separate partition or UBI volume is used as "data", in other cases the old > configuration (network configuration, ..) is saved and restored. What I'm focused right now is in /etc and /var directories. Here is the information to boot the system with the required configuration, including partition and network configuration. > > This is done by using the pre- and postinstall feature of swupdate. A > swupdate image contains scripts that allow a migration of data from a > version to the next one. The idea here is to provide a swupdate cpio file with prescripts to save the configuration data and a postinstall script to restore the data. It is a good option, but the user would need to supply these scripts for every update. I would like to avoid that if possible. > > At the moment, a general case to save data is foreseen if data are saved > into a UBI volume and volumes must be repartitioned. In this case, data are > saved and restored after repartitioning. There was a discussion in the mailing list in this thread: http://lists.openembedded.org/pipermail/openembedded-devel/2015-November/104800.html The conclusion for this thread is as follows: 1. One size doesn't fit all. 2. Most of the people was fine with the image based update. 3. The recommended way to keep the configuration is to have a separated data partition. 4. The partition scheme would be: a. boot. This is the usual boot partition b. rootfs. Partition used for normal operation. c. maintenance. This partition will be used to update rootfs. d. data. This will hold the configuration files. Not modified by updates. With this input will create a template for wic. This has changed direction several times. If we have a decent proposal of what we should do lets consider that as a specific proposal and close this randomly changing direction bug. |