--- title: "Using Update Packages" slug: "using-update-packages" description: "Use update packages in icom Router Management to deploy firmware, configs, containers, and licenses - secure, scalable, and ideal for industrial router fleets." tags: ["icom Router Management", "iRM"] updated: 2025-11-11T09:32:55Z published: 2025-11-11T09:32:55Z canonical: "docs.insys-icom.com/using-update-packages" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.insys-icom.com/llms.txt > Use this file to discover all available pages before exploring further. # Using Update Packages Update packages are a central mechanism for deploying files to icom OS-based routers. They enable efficient, structured management of device software, configurations, and applications across single routers or large device fleets. An update package consists of: - A manifest file (text format) describing the package contents - One or more files to be stored or executed on the router - The package itself is an uncompressed tar archive (.tar) containing the manifest and associated files Update packages are essential for: - Firmware updates (full or incremental) - Deployment of configurations, including binary and ASCII configurations - Installation of containers (Linux containers) - Application of licenses - Updates to container storage or configurations ## What Can Be Deployed via Update Packages The types of files supported within an update package include: | File Type | Description | | --- | --- | | Full Software Update | Major icom OS firmware release (e.g., v7.0, v8.0) | | Incremental Software Update | Minor icom OS firmware update (e.g., v8.0 to v8.1) | | Binary Configuration | Router profile in binary format | | ASCII Configuration | Plain-text configuration commands applied immediately after upload, not stored persistently | | Stored ASCII Configuration | ASCII configuration stored on the router for later use | | OpenVPN Configuration | OpenVPN .ovpn files integrated into router VPN settings | | Container | Linux-based application containers (LXC) | | Container Configuration | Tar archives representing a container’s internal configuration (/data/etc) | | License | Licenses unlocking specific container functionalities | | Full Storage | Full tar archives for container storage, replacing existing files | | Incremental Storage | Tar archives for partial updates to container storage (overwrite only existing files) | | Bootloader, DSL Update | Specialized system components like bootloaders or DSL modem firmware | | OEM Branding | Predefined factory settings | If you need more information on how to create your own update packages, please refer to the following article: [Creating Own Update Packages](/kb/docs/creating-own-update-packets-en). > [!NOTE] > Note > > Update packages can also be signed and/or encrypted for additional security. --- ## The Manifest File At the heart of every update package lies the manifest — a strict, line-based text file defining each included file. - Filename: Always MANIFEST (without extension) - Format: ASCII or UTF-8 (without BOM) - Structure: Key-value pairs (no spaces around "="), case-sensitive Main manifest keywords: | Keyword | Meaning | | --- | --- | | FILENAME | Name of the included file (mandatory) | | FILETYPE | Defines the type of file (mandatory) | | MD5SUM | MD5 checksum of the file (mandatory) | | FILESIZE | File size in bytes (optional) | | DESCRIPTION | Free-text description (optional) | | VERSION | Firmware or file version (mandatory for some file types) | | REQUIRED_SW | Required existing firmware version (for incremental firmware updates) | | KEY | Key description for encrypted containers (optional) | > [!NOTE] > Note > > The order of sections in the manifest determines the installation sequence. For example, a container must be installed before its configuration can be applied. --- ## ASCII Configurations via Update Packages ASCII configurations are a particularly flexible form of applying configuration settings: - They consist of router commands in a simple text format - When included in an update package as FILETYPE=ASCII Configuration, they are immediately executed upon upload - They are not permanently stored unless specifically defined as Stored ASCII Configuration Typical use cases for ASCII configurations: - Initial router provisioning - Mass updates of specific settings (e.g., firewall rules, VPN settings) - Activation of features without manual web UI interaction > [!TIP] > Info > > ASCII configurations allow highly automated rollouts without requiring the routers to be manually accessed or reconfigured. ## Combining Multiple Elements into a Single Update Package Update packages can combine several types of updates in one deployment: - Firmware and container - Container and configuration - Multiple configurations (ASCII and binary) - And others To achieve this, the individual packages must first be unpacked, and then a new combined update package must be built with a fresh manifest listing all files. If you need more information on how to create your own update packages, please refer to the following article: [Creating Own Update Packages](/kb/docs/creating-own-update-packets-en). ## Security Considerations - Update packages can be signed and/or encrypted to guarantee integrity and authenticity. - Routers can be configured to accept only signed update packages. - This is especially critical in environments with strict cybersecurity or compliance requirements (e.g., CRA, IEC 62443). - When uploading an update package to icom Router Management (iRM), a checksum is automatically calculated and stored using the MD5 algorithm to secure data integrity. - This MD5 checksum can be used to verify the integrity of the update package when downloading it at a later time. The user must locally recalculate the MD5 hash of the downloaded file and compare it to the checksum stored in the system.