CUBEMX Docker Integration and offline mode

[mani9989]

1. Issues with Headless Execution and CLI Commands

• GUI Opens with CLI Flags: Certain CLI flags designed for automation still launch the AWT/Swing GUI components, which causes failures in headless environments (like Docker containers or typical Linux servers).
  • Specific Example: The -P flag (Package Manager) throws a java.awt.AWTError: Can't connect to X11 window server error because it requires a display.
  • Expected Behavior: All package management and code generation functions should have a truly headless (no GUI dependencies) CLI option that works universally in server environments.
• Lack of Clear CLI Documentation: Documentation for reliable, headless CLI commands (like swmgr install) is sparse or non-existent in the official user manual (UM1718), leading to trial-and-error with internal commands.

2. Issues with Offline Package Management and Database Indexing

• Discrepancy Between Repository and Database Paths: Manually placing firmware package ZIP files into the designated repository path (/root/STM32Cube/Repository/) is insufficient. The application fails to automatically index these files into its internal database path (/root/STM32CubeMX/db/mcu/).
  • Resulting Error: This leads to the persistent error: [ERROR] .../STM32H5xx_I2c.ioc.xml doesn't exist and MCU is unknown, even when the package files are physically present in the correct repository location.
• Forced GUI Interaction for Installation: A functional installation and database registration appears to require running the GUI (either natively or via X11 forwarding) at least once to formally "install" the packages, which is a major hurdle for automated Docker builds and headless servers.

3. Network and Certificate Handling Issues

• Persistent Network Checks in Offline Mode: Even when running CubeMX with the -offline flag, internal threads (IntegrityCheckThread, ThirdPartyUpdater) still attempt network connections during startup.
• PKIX/Certificate Errors (Proxy Issues): These background checks often fail in corporate environments using proxies that intercept SSL certificates, resulting in PKIX path building failed errors.
• Startup Delays: The network timeouts and retries caused by the certificate errors add significant, unnecessary delays to startup time in automated scripts.

4. Docker Specific Issues

• Complex Dockerfile Execution: Automating the installation process within a Dockerfile is fragile due to the reliance on X11 forwarding (Xvfb) within a single RUN command, leading to permission and execution errors (/bin/sh: 1: : Permission denied).

[Ghofrane GSOURI]

Hello @mani9989 

Thank you for your valuable feedback.

To help us reproduce your issue, please provide detailed information about your environment, including the operating system and version, Docker version, Java version and  STM32CubeMX version.

Specify the exact CLI commands and flags you used, along with any environment variables that were set. Share your complete Dockerfile and any entrypoint or shell scripts involved in the process.

Describe the file and directory structure, particularly where the package ZIP files are placed, and include the contents of both /root/STM32Cube/Repository/ and /root/STM32CubeMX/db/mcu/. Please provide the full error messages and stack traces you encountered, as well as the console output from your attempts. If you are behind a proxy, include your proxy settings. Finally, outline the step-by-step actions you took leading up to the issue. This comprehensive information will help us accurately reproduce and diagnose your problem.

THX

Ghofrane

[JesperEC]

Hi,

I can add that the problem

---

@mani9989 wrote:

3. Network and Certificate Handling Issues

• Persistent Network Checks in Offline Mode: Even when running CubeMX with the -offline flag, internal threads (IntegrityCheckThread, ThirdPartyUpdater) still attempt network connections during startup.

is not Docker specific. I can reproduce it running 6.15.0 on Debian bookworm in a standard terminal without Docker. Because of reasons, this machine does not have a connection to the internet - not even via proxy. This of courses makes many features of STM32CubeMX not working but we are using it to re-generate code based on previously downloaded STM32Cube packages.

In Help / Connection & Updates, I have set
Check and Update Settings: Manual Check

Data Auto-refresh: No Auto-Refresh at Application start

Still, when starting there is a 40 second delay with a frozen splash screen while the program tries to connect to https://sw-center.st.com:443 15(?) times before giving up. The log printed to the console is

2025-11-19 15:35:28,813 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [2/15]
2025-11-19 15:35:31,814 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [3/15]
2025-11-19 15:35:34,815 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [4/15]
2025-11-19 15:35:36,181 [INFO] RetryExec:97 - I/O exception (java.net.SocketException) caught when processing request to {s}->https://sw-center.st.com:443: Network is unreachable
2025-11-19 15:35:36,184 [INFO] RetryExec:113 - Retrying request to {s}->https://sw-center.st.com:443
2025-11-19 15:35:37,817 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [5/15]
2025-11-19 15:35:40,818 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [6/15]
2025-11-19 15:35:43,819 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [7/15]
…
2025-11-19 15:36:04,826 [INFO] ThirdPartyUpdaterWithRetryManager:70 - Updater plugin not ready yet. [14/15]
2025-11-19 15:36:06,237 [INFO] MainUpdater:2872 - connection check result : 22
2025-11-19 15:36:06,239 [INFO] MainUpdater:289 - Updater Check For Update Now.
2025-11-19 15:36:06,239 [INFO] MicroXplorer:498 - Change Database Version : DB.6.0.150

    Best regards, Jesper

[mani9989]

Hello Ghofrane

Here is the detailed information regarding my environment to help you reproduce and diagnose the issue I am facing.

Folder Structure 
├── auto-install.xml
├── Dockerfile
├── generate_ioc.script
├── local
│   └── install_stm32cubemx.sh
├── stm32cubemx-lin-v6-15-0.zip
└── STM32H5xx_I2c.ioc

├── st_packages
│   ├── stm32cube_fw_h5_v150.zip
│   └── stm32cube_fw_h5_v151.zip

│   └── Repository.zip

1. Set up Base System: Start with a clean Ubuntu 22.04 operating system and configure it for non-interactive automation.
2. Install Prerequisites: Install Java 21, various utilities (unzip, wget), and graphics libraries needed to run the software headlessly.
3. Define Locations: Set environment variables to tell the system where Java is installed and where STM32CubeMX will be placed.
4. Copy Installer: Move the STM32CubeMX zip file, the automatic installation configuration file (auto-install.xml), and local firmware packages into a temporary staging folder (/st).
5. Run Installation: Unzip the installer, make it executable, and run the silent installation process within the container.
6. Add Project Files & Scripts: Copy your project files (.ioc), automation scripts, into the container, then make the scripts executable.
7. Verify Installation Path: Use system commands to locate the exact path of the newly installed STM32CubeMX executable file.
8. Initialize Software Headlessly: Use a virtual display (Xvfb) to start STM32CubeMX for the first time, allowing it to initialize its internal databases without needing a physical screen.
9. Fetch Hardware Libraries (Optional):  extract a local Repository.zip or copy the packages from st_packages to provide the STM32Cube/Repository.
10. Set Default Action: Configure the container to start in the /st folder and automatically run your code generation script when executed.

Expectations 

- Install StM32cubeMX silent mode using auto_install.xml

- Link / Load Offline Packages downloaded from ST website  

- Generate code based on the provided .ioc file silent mode 

Best Regards,

Mani 

[mani9989]

@Ghofrane GSOURI  - Any update on this topic ?

[Ghofrane GSOURI]

Hello @mani9989

---

@mani9989 wrote :Network and Certificate Handling Issues
Persistent Network Checks in Offline Mode: Even when running CubeMX with the -offline flag, internal threads (IntegrityCheckThread, ThirdPartyUpdater) still attempt network connections during startup.
PKIX/Certificate Errors (Proxy Issues): These background checks often fail in corporate environments using proxies that intercept SSL certificates, resulting in PKIX path building failed errors.
Startup Delays: The network timeouts and retries caused by the certificate errors add significant, unnecessary delays to startup time in automated scripts. 

@Ghofrane GSOURI  Offline  mode is not  supported in CubeMX.

---

---

@mani9989 wrote:

Add Project Files & Scripts: Copy your project files (.ioc), automation scripts, into the container, then make the scripts executable.

@Ghofrane GSOURI  Could you kindly share the automation scripts you are utilizing? Furthermore, please specify the CLI commands  you employ to launch CubeMX.

---