[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg divert in preinst scripts





Yes.  Updates are handled by installing an entire new filesystem image,
and the device boots to the new filesystem.  Most products that are
mission critical will have the ability to revert back to the previous
version if booting of the new filesystem fails, or the user decides the
new version is unsuitable (e.g. incompatibilities or interoperability
issues, etc).

Where is the previous version kept? On device? As long as there's
enough room you can do that with Baked - it would be a question of how
you put the Baked rootfs onto the device.


Yes, the previous version would be on the device.  It needs to be in
case the update fails and an automatic fallback is required.  Think of
remotely updating a router that is located in the middle of nowhere
(where maintenance personal visit infrequently).

In my experience, this is well handled within the domain of the bootloader. For ARM devices (and others platforms too), a bootloader such as U-Boot is quite well equipped to handle multiple boot images. For an embedded system, using initramfs for the filesystem is a fine way to proceed, storing the filesystem initially in flash and then loading it into RAM before booting. If flash space is a constraint, a single flash image can be maintained with the update process overwriting the root filesystem on upgrade. You can then have your recovery mechanism be entirely in the bootloader domain, coding in the ability to rewrite the filesystem image from the bootloader to recover a corrupted image.

There are a few ways of doing this.  Each FS could live in it's own
partition, or images can be stored on a common partition and loaded
somehow (e.g. loop device).  Kernel images may or may not live in the
fs, depending on the bootloader capabilities of the embedded system.
The kernel may or may not need to use initramfs.

Bootloaders such as U-Boot work well with the kernel stored separately from the root filesystem. This allows the flexibility to store the root filesystem in any number of compressed formats. The kernel gets loaded and off the ground and then can mount root filesystems such as SQUASHFS or SQUASHFS-LZMA, which which save considerably on flash storage space.


As far as configuration is concerned.  Most user settable values are
stored in a common location (e.g. an eeprom, or a dedicated partition,
etc).  These values are used by the running linux system (which ever it
is).  An example would be hostname, IP address, etc.

Once again, U-Boot offers the ability to store lots of system specific information (IP addr, etc) in the form of environment variables, that can be subsequently passed to the Linux kernel on boot (the technique employed varies from architecture to architecture).


-Jim Heck


Reply to: