Linux-based Firmware, how to implement a good upgrade method?

Question

I am developing a Linux device using alix 2d13.

I developed a script that takes care of creating the image file, creating partitions, installing the bootloader (syslinux), kernel and initrd, and that takes care of the root filesystem files to the right of the partition.

The configuration files are located on the tmpfs file system and are created at system startup using software that reads an XML file that is located on its own section.

I am looking for a way to update the file system, and I examined two solutions:

• A firmware update is a compressed file that can contain a kernel, initrd and / or rootfs partition, so when restarting initrd will make sure that the rootfs image is in the correct partition;
• A firmware update is a compressed file that can contain two tar archives, one for download and one for the root file system.

Each solution has its advantages: - the image of the file system will allow me to delete any unused files, but you need a lot of time, and it will quickly destroy the compact flash memory; - the archive is smaller, it takes less time to update, but in a short time I will have caos in the root file system.

An alternative solution would be to place a list of files and add a pre / post update script to the tar archive, so any file that is not in the list of files will be deleted.

What do you think?

Answer 1

I used the following approach. This was somewhat based on the Murphy Compatible Linux Embedded Systems document available here . I used the version.conf material described in this article, and not the cfgsh material.

• Use a bootable kernel whose job is to reconnect to the root file system. If you need a newer kernel, then kexec into this new kernel immediately after installing it. I decided to put the boot kernel in init init in initramfs along with busybox and kexec (both are statically linked), and my init was a simple script shell that I wrote.
• In the OS image file system, there is one or more root filesystems of the "main OS" in the form of disk image files. The download kernel selects one of them based on the version.conf file. I support only two main OS image files: current and emergency files. If the current failure (more on detecting failures later), then the boot kernel loads the decline. If both fail or fail, the boot kernel provides a shell.
• The system configuration is on a separate section. Usually this is not updated, but there is no reason why it could not be.
• There are four complete sections: boot, OS image, configuration, and data. The data section is for custom applications designed for frequent writing. boot is never mounted read / write. An OS image is only a (re) mounted read / write during updates. config only mounts read / write when configuration needs to be changed (hopefully never). data is always set to read / write.
• Each disk image file contains a complete Linux system, including the kernel, initialization scripts, user programs (such as busybox, product applications) and the default configuration, which is copied to the configuration section on first boot. Files are sized to accommodate all of them. As long as I have enough room for growth so that the OS image section is always large enough to fit the three main OS image files (during the upgrade, I will not delete the old rollback until the new one is extracted), I can The main OS image evolved as needed. These image files are always (loop-back) installed read-only. Using these files also eliminates the pain of failing to update individual files inside rootfs.
• Modifications are performed by transferring the self-extracting tarball to tmpfs. The beginning of this script reinstalls the image / image of the OS image, then extracts the new main OS image to the file system of the OS image, and then updates the version.conf file (using the renaming method described in the "murphy" document). After that, I will touch the stamp file, indicating that an update has occurred, and then reboot.
• The download kernel looks for this stamp file. If he finds it, he will move it to another stamp file, and then upload a new OS image file. The main OS image file is expected to delete the stamp file when it starts successfully. If this does not happen, the watchdog will cause a reboot, and then the boot kernel will see this and detect a failure.
• You will notice that during the upgrade there are several possible problems: synchronizing .conf versions during the upgrade and touching / deleting the stamp files (three instances). I could not find a way to reduce them further and achieve everything that I wanted. If anyone has a better offer, I would like to hear it. File system errors or power outages when recording an OS image can also occur, but I hope the ext3 file system gives you a chance to survive in this case.

Answer 2

You may have a separate section for updating (Say Side1 / Side2). The existing kernel, rootfs, is located in Side1, and then adds the update to Side2 and switches. Thanks to this, you can reduce wear and increase service life, but the device becomes more expensive.

Answer 3

You can quickly format partitions before extracting tar files. Or go with the image resolution, but use the smallest possible image even after dd resizes the file system (although this is not necessary for reading in real time)