Installing STM32 CubeFamily on Fedora Kinoite Immutable Linux Distro

In this blog, I share my experience installing and running the STM32 CubeFamily tools on Fedora Kinoite—a Linux distribution with an immutable root partition. This post covers some lesser-known challenges and workarounds in the Linux and STM32 world, especially when working with an immutable OS. Note: Screenshots are indicated as placeholders (e.g., [image]) and can be added later.

Overview

The STM32CubeMX and STM32CubeProgrammer tools can be installed and executed without modifying the root partition. However, there are some nuances:

STM32CubeMX and STM32CubeProgrammer run on a read-only filesystem if they do not need to change system partitions.
STM32CubeProgrammer may sometimes require root privileges because it installs udev rules (e.g., in /etc/udev/rules.d/). It also works only when run as root.

In contrast, STM32CubeMxIDE poses more challenges due to its installation process requiring write access to the system, which is not available on an immutable filesystem.

STM32CubeMxIDE Installation Challenges

When trying to install STM32CubeMxIDE using the RPM Linux installer, the following errors were encountered:

error: can't create transaction lock on /usr/share/rpm/.rpm.lock (Read-only file system)  
error: can't create transaction lock on /usr/share/rpm/.rpm.lock (Read-only file system)  
./setup.sh: line 21: yum: command not found  
./setup.sh: line 21: yum: command not found

The error clearly indicates that the root partition is read-only. Even attempting to use a distrobox led to further issues:

The IDE installed with some errors, and although it could be launched, the STLink programmer did not show up even after scanning in the debugger configuration.
The lsusb command confirmed that the programmer was plugged in, but an error appeared in the terminal, and adding udev rules within the container resulted in a permission error:

sudo udevadm control --reload-rules  
Failed to send reload request: Permission denied

Screenshot placeholder: [image showing STM32 CubeProgrammer which says “disconnected”]

If the programmer was not plugged in, the tool correctly indicated the absence of the device. However, when plugged in and scanned, the list remained empty after a brief freeze. Multiple trials (adding dialout, usb groups, manually copying udev rules) did not resolve the issue.

Using Distrobox with Root Permissions

A successful workaround was found by creating a distrobox with root permissions:

Non-root Container Setup: bashCopyEdit# Open and create non-root container distrobox-create --name my-fedora-container --image fedora:latest distrobox enter my-fedora-container # Install IDE and Programmer # exit container
Root Container Setup: bashCopyEditdistrobox-create --name stm32 # This gets registry.fedoraproject.org/fedora-toolbox:latest distrobox enter --root stm32 # Install programmer and IDE # Exit # Enter container without root and run IDE with root

This method appeared to apply non-root changes (which still required root permission) that allowed the IDE to work properly in the non-root container. However, the IDE would periodically freeze, prompting a decision to try the generic Linux installer outside of any container.

Installing the STLink Server

Once the IDE was working and showing the STLink as available (but not running a debug session), an error was encountered:

Screenshot placeholder: [image showing “STM32CubeIDE launching debug session failed, ST-Link server is required”]

Attempts to install the STLink server faced challenges:

RPM installation did not work because the system is locked.
Commands like ostree-rpm install and the shell script installer (sh) failed.
Installing the STLink server in a container and running the IDE outside the container did not work.

A new approach was taken by creating another root container and running the IDE installer as root inside it. This method worked without critical errors, apart from some warnings:

bashCopyEditpackage st-stlink-server-2.1.1-1.x86_64 is already installed
>>> Running post-install scriptlet: libgcc-0:14.2.1-7.fc41.i686
warning: posix.fork(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.spawn() or rpm.execute() instead  
warning: posix.wait(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.spawn() or rpm.execute() instead

Even after installing the STLink server in the root container, periodic issues were encountered in STM32CubeIDE (possibly due to it not running as root). For example:

When opening a project:
Screenshot placeholder: [image showing error “could not write metadata for /” with detailed issues]
After closing the IDE:
Screenshot placeholder: [image showing “STM32CubeIDE cannot save changes due to permission denied”]

Running the IDE as root inside the container resolved these permission issues.

Aftermath and Final Observations

After resolving the installation and configuration challenges, a couple of other issues were noted:

Compilation Issue: There were duplicate entries that led to a compilation failure: xmlCopyEdit<link> <name>Drivers/BSP/Component/lan8742.c</name> <type>1</type> <locationURI>PARENT-1-PROJECT_LOC/Drivers/BSP/Components/lan8742/lan8742.c</locationURI> </link> <link> <name>Drivers/BSP/STM32H7xx_Nucleo/lan8742.c</name> <type>1</type> <locationURI>PARENT-1-PROJECT_LOC/Drivers/BSP/Components/lan8742/lan8742.c</locationURI> </link> Removing these duplicate entries was necessary, or compilation would fail with errors regarding multiple declarations.
Runtime Error: Occasionally, an error related to libusb was encountered: Screenshot placeholder: [image showing “libusb device xyz is still referenced”]
Despite the error, the flashing process eventually completed successfully, and the program ran on the STM32 Nucleo board (which has the STLink built in).

Conclusion

This experience highlights some of the lesser-known issues that arise when installing STM32 tools on an immutable Linux distro like Fedora Kinoite. The key takeaways are:

Read-Only Filesystem Constraints:
Some tools, like STM32CubeMxIDE, are not designed for an immutable root partition and may require creative workarounds.
Using Distrobox:
Creating a root-enabled container can circumvent many permission issues, though it might introduce periodic freezes or warnings.
STLink Server Installation:
Installing the STLink server required a root container environment to avoid system lock issues.
Handling Duplicate Files and Runtime Errors:
Duplicate file declarations and libusb errors are additional challenges to be aware of.