You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
detect_pinmap hard codes /proc/device-tree/model causing non-privileged docker containers to fail hardware autodetect. This is a common issue that is being worked around by either A) making the container privileged B) Or wait for the container to come up then perform some kind of just in time post start remount. Both solutions are not ideal.
There was another issue that partially resolved the problem but did not address the hardware autodetect failure. See Here
On a container, /proc/device-tree is actually a symbolic link to /sys/firmware/devicetree/base, but /sys/firmware doesn't exist at all. Simply mounting /sys/firmware/devicetree/base as a volume does not appear to work.
However, you CAN mount /sys/firmware to another path while non privileged. Like so:
/psys is just a made up path. So a simple solution might be to not hard code /proc/device-tree/model and allow it to be changed from gpio.init. like this:
…#154 rather than assume /proc/device-tree/model
This allows non privileged docker containers to specify a different path for the model file since it can't use /proc/device-tree/model
masahji
added a commit
to masahji/node-rpio
that referenced
this issue
Nov 24, 2021
…#154 rather than assume /proc/device-tree/model
This allows non privileged docker containers to specify a different path for the model file since it can't use /proc/device-tree/model
…#154 rather than assume /proc/device-tree/model
This allows non privileged docker containers to specify a different path for the model file since it can't use /proc/device-tree/model
detect_pinmap
hard codes/proc/device-tree/model
causing non-privileged docker containers to fail hardware autodetect. This is a common issue that is being worked around by either A) making the container privileged B) Or wait for the container to come up then perform some kind of just in time post start remount. Both solutions are not ideal.There was another issue that partially resolved the problem but did not address the hardware autodetect failure.
See Here
On a container,
/proc/device-tree
is actually a symbolic link to/sys/firmware/devicetree/base
, but/sys/firmware
doesn't exist at all. Simply mounting/sys/firmware/devicetree/base
as a volume does not appear to work.However, you CAN mount
/sys/firmware
to another path while non privileged. Like so:/psys
is just a made up path. So a simple solution might be to not hard code/proc/device-tree/model
and allow it to be changed fromgpio.init
. like this:The text was updated successfully, but these errors were encountered: