Feature #447
closed
Need upgrade path
100%
Description
There is no way to upgrade a system. I need one.
Plan A¶
Create 4 partitions:- p0: FAT/boot
- p1: EXT4/Minimal update
- p2: EXT4/Runtime
- p3: EXT4/User Data w/update files area
An update causes a reboot into p1 which does the update to p2 and then reboots into P2. This takes the system out of action during the update but probably not for long as long as the update image has already been downloaded.
This also assumes that the update is a complete rewrite of the boot partition. That may not be desirable.
Plan B¶
Always use opkg's, even for files already on the rootfs.
Create 3 partitions:- p0: FAT/boot
- p1: EXT4/Runtime
- p2: EXT4/User Data w/update files area
For example, a kernel update would be downloaded as an opkg and installed over the existing kernel (essentially). This requires postinst processing to switch to the new kernel (copy to p0).
The question is how will the system behave when not all files are initially package controlled. Replacing system files with opkg files may present problems.
Overview of the image and updates¶
The image build (re: rootfs) sits on a two partitions. The first is a vfat partition required by the bootloader. The second is the rootfs. Both are images copied byte-for-byte to their respective partitions in order to create the boot SD card. An update process can either update specific packages (of which there are none for the base platform) or it can replace the partition image. The latter is often required in embedded systems and might be more appropriate for PiBox unless PiBox switches to a fully package managed system.
An update to the rootfs can be done in place. A secondary rootfs partition can be installed and the boot process pointed at it so the next boot uses it. This requires a mechanism to fallback to the original partition if something fails in the new partition. A key sequence or other extenal impetus at boot time would be required to force the fallback.
The boot partition can't use an alternate. So files have to be where we expect them. The boot partition also doesn't use symlinks so we can't place alternates in directories and just update the symlinks. This implies that we have two directories, current and new, that contain the data to boot. Within that data is a kernel with an initramfs capable of replacing the booting kernel with the older version if the boot process fails.
The rootfs update is not overly difficult. It requires an extra boot script that validates the running system and resets if anything goes wrong. This verification tests that all components are online correctly, specifically wireless and USB support.
The boot partition update is more complex since it requires an error checking mechanism built into the initramfs. This error checking would be to verify that all drivers are available and can load without error.
Updated by