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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
