We are developing a .NET 6 application to run on TorizonCore and we need to read SoC and module information. For SoC information we are reading files from /sys/devices/soc0/.
We didn’t know how to obtain the module information but we found the following article:
Using the tdx-info script source code as a reference we tried reading files from /proc/device-tree/ but we get the following exception:
System.IO.DirectoryNotFoundException : Could not find a part of the path '/proc/devicetree/model'.
We also noticed that /proc/device-tree is a link to /sys/firmware/devicetree/base so we tried reading files from this path as well but we got the same exception. We also tried mounting both of these paths as docker volumes but the result was the same.
Finally we tried running the app container as privileged (we added the privileged key with a value of True to the extraparams setting) and it worked.
We want to run the app container with as few privileges as necessary.
Is there some way to read files from these paths without running the container fully privileged?
Can you share the docker run command with us? Are you bind mounting the /proc folder inside the container?
And additional information, the /proc/device-tree is a system link to another file, so if you bind mount only the /proc/devicetree is not going to work, since the other file linked is not available inside the container.
Out of curiosity, what information specifically are you trying to determine? Perhaps there’s other ways to get this information without trying to parse /sys or /proc in a container.
We are not running docker from the command line, we are debugging the project from vscode with the Toradex Torizon Support extension. I can share parts of our config.yaml, which parts should I share?
We tried mapping the /proc folder as a volume. We figured bind mounts and volumes are not the same but we don’t know to setup a bind mount, con you provide instructions?
Yes, we noticed this, so we tried accessing the /sys/firmware/devicetree/base instead, but we get the same error. As I mentioned previously we probably didn’t configure the bind mount correctly for this to work.
We are porting code from an application that used to run on .NET Compact Framework 3.5 on top of WinCE7 on several Colibri SoM (PXA 270, PXA 320 and TegraT20). The application relied mostly on the Legacy Windows CE Software Libraries for PXA and Tegra Modules (wincelib_bin_V2_0_2865) and some parts on the more recent Toradex CE Libraries (toradexcelibraries_v1_6_3123).
The Coproc and SysInfoLib modules from the aforementioned libraries lets the application probe for SoC and SoM information to configure itself accordingly. We now need to do the same with the iMX6 and iMX8 modules. We need to probe for:
I see, getting all this information in a container would be tricky. Especially taking into account all the different bind-mounts and permission levels that would need to be handled without giving the container too many privileges.
As an alternative idea, would it make more sense to gather this information outside of the container where it is more accessible, then pass the information into the container?
For example you could have a script that runs on the host OS that gathers this information and writes it to a file or something similar. Then your container just needs to bind-mount this one file and can parse all the information from this file. In this way you wouldn’t need to give the container any elevated privileges except access to this one file. Not saying you have to do it this way but it could be more compatible with what you’re trying to achieve.
What script type would you recommend, bash? How do we configure the script to run before the application container?
Bash would be the most accessible scripting language that’s available on the host OS by default. As for running your script you could create a custom systemd service that executes your script before the systemd service “docker-compose.service” runs. This is the service that auto-starts your containers in production. Otherwise for development purposes you can just run the script prior to debugging/executing your container.
What is the recommend way of storing information on the host OS for the container to access it later? a file? what would “something similiar” be?
Well I just said a file cause it’s the most straightforward method. But you could store the information as environment variables and pass them to the container. I’m sure there’s other methods but this is more of a design choice on your side then there being a “right” way.