Prep customer image: Difference between revisions

From embeddedTS Manuals
(Added quotes around a name, added clarification on compression method by script.)
(Update to note that the script can be used to extract image from SD/eMMC on a booted device.)
Line 4: Line 4:




The simplest usage of the script is:
The simplest use of the script is:
<source lang=bash>
<source lang=bash>
./prep_customer_image /dev/sdX <output base name>
./prep_customer_image /dev/sdX <output base name>
Line 10: Line 10:
Note that "/dev/sdX" will need to be changed accordingly.  Be sure to pass the whole disk and not just a partition.
Note that "/dev/sdX" will need to be changed accordingly.  Be sure to pass the whole disk and not just a partition.


The <output base name> is used as the base for all files output.  For example, if "TechnologicSystems-latest" was used, then the compressed tarball output would be named "TechnologicSystems-latest.tar.bz2" (or it may end with ".tar.xz" depending on the compression used by the script).  If no base name is provided, then the current date is used.
The "<output base name>" is used as the base for all files output.  For example, if "TechnologicSystems-latest" was used, then the compressed tarball output would be named "TechnologicSystems-latest.tar.bz2" (or it may end with ".tar.xz" depending on the compression used by the script).  If no base name is provided, then the current date is used.


Additionally, there are two hooks available in the prep_customer_image script, prep and post.  The top of the file has two variables, PREP_SCRIPTS="" and POST_SCRIPTS="".  Adding in a space separated list of script names to those variables will cause them to be called in order.  For example, setting PREP_SCRIPTS="add_application change_hostname" will cause the prep_customer_image to run through its initial steps, then call ./add_application, then call ./change_hostname, and then will continue with the rest of the script steps.
Additionally, there are two hooks available in the 'prep_customer_image' script, "prep" and "post".  The top of the file has two variables, `PREP_SCRIPTS=""` and `POST_SCRIPTS=""`.  Adding in a space separated list of script names to those variables will cause them to be called in order.  For example, setting `PREP_SCRIPTS="add_application change_hostname"` will cause the 'prep_customer_image' script to run through its initial steps, then call './add_application', then call './change_hostname', and then will continue with the rest of the script steps.


Every script for prep and post is called with a single argument, the name of the image file.  This specifically will be "<output base name>.dd".  At the time of calling the prep scripts, the folder ./mount_point/ will have the last partition of the image file mounted as read/write.  It is not wise to modify the image file directly since it is already mounted.  All of the post scripts are called after the last partition of the image file is unmounted. This can be useful for creating additional file outputs, pulling out specific partitions, etc. from the image itself.  We have used these hooks in the past to remove special files and create additional images for our DoubleStore based devices.
Every script for "prep" and "post" is called with a single argument, the name of the image file.  This specifically will be "<output base name>.dd".  At the time of calling the prep scripts, the folder "./mount_point/" will have the last partition of the image file mounted as read/write.  It is not wise to modify the image file directly since it is already mounted.  All of the post scripts are called after the last partition of the image file is unmounted. This can be useful for creating additional file outputs, extracting specific partition images, etc., from the image itself.  We have used these hooks in the past to remove special files and create additional images for our DoubleStore based devices.
 
It is also possible to run this script directly on the device when booted. This can be used to take an image of eMMC for example, when booted from the SD card. We always recommend doing initial development on SD, creating an image from that on a host PC, and then transferring it to the eMMC. This process makes development and image creation faster. If using the 'prep_customer_image' script from a booted device, be sure there is enough free space as the script creates a disk image of the target disk and then copies that in to a tarball, compressing everything as the final step.

Revision as of 17:27, 10 July 2019

It is usually desired to create a golden image to use for unit production after development is complete. This process can vary greatly from application to application but there are a few steps that are going to be most often wanted. These include cleaning up temporary files, removing files that should be unique and re-generated on the first boot (SSH keys, machine-id files, etc.), setting up the hostname, and so on. We have created a script that will automate most of this process and provides hooks for additionally scripts to be called as well. The script is simply passed the device node of the development disk or an existing .dd file. From this, it will create a new .dd file based on the partition scheme with all modifications made to the new image. The image source is left completely untouched and is only read. The script also assumes that the last partition on the disk is the bootable linux partition. If this is not the case or there are multiple partitions that are used in the end application, the script will need to be modified in order to accommodate this fact.

Note: The script uses output from various commands. The output format of linux utilities can vary greatly from distribution to distribution, or even within versions of the distribution. It is strongly recommended to verify the final processed image contains everything necessary for the application and that all processes completed without issue.


The simplest use of the script is:

./prep_customer_image /dev/sdX <output base name>

Note that "/dev/sdX" will need to be changed accordingly. Be sure to pass the whole disk and not just a partition.

The "<output base name>" is used as the base for all files output. For example, if "TechnologicSystems-latest" was used, then the compressed tarball output would be named "TechnologicSystems-latest.tar.bz2" (or it may end with ".tar.xz" depending on the compression used by the script). If no base name is provided, then the current date is used.

Additionally, there are two hooks available in the 'prep_customer_image' script, "prep" and "post". The top of the file has two variables, `PREP_SCRIPTS=""` and `POST_SCRIPTS=""`. Adding in a space separated list of script names to those variables will cause them to be called in order. For example, setting `PREP_SCRIPTS="add_application change_hostname"` will cause the 'prep_customer_image' script to run through its initial steps, then call './add_application', then call './change_hostname', and then will continue with the rest of the script steps.

Every script for "prep" and "post" is called with a single argument, the name of the image file. This specifically will be "<output base name>.dd". At the time of calling the prep scripts, the folder "./mount_point/" will have the last partition of the image file mounted as read/write. It is not wise to modify the image file directly since it is already mounted. All of the post scripts are called after the last partition of the image file is unmounted. This can be useful for creating additional file outputs, extracting specific partition images, etc., from the image itself. We have used these hooks in the past to remove special files and create additional images for our DoubleStore based devices.

It is also possible to run this script directly on the device when booted. This can be used to take an image of eMMC for example, when booted from the SD card. We always recommend doing initial development on SD, creating an image from that on a host PC, and then transferring it to the eMMC. This process makes development and image creation faster. If using the 'prep_customer_image' script from a booted device, be sure there is enough free space as the script creates a disk image of the target disk and then copies that in to a tarball, compressing everything as the final step.