How to mount /lib/firmware RW

My apologies if this is an ignorant question, I have googled and searched this forum but have been unable to find the answer. I wanted to try to add wireless support to an unsupported board (everything works except wireless) during the build process. However, in order to do this I need to mount /lib/firmware RW.

I appreciate the assistance.

Hi Rob!

/lib/firmware is part of the host OS filesystem, and changing it would either block Resin OS updates, or overwrite them on every update – As this could leave devices in a non functioning state, Resin OS doesn’t allow modifications to it by default.

That said, it is certainly possible to load custom kernel modules and/or firmware from a container. If you put the firmware in the containers /lib/firmware (instead of mounting the host OS’s), and load the required kernel module from there, that generally works well.

Alternatively, there might be a way to specify an alternative location for the firmware in the drivers?

I found this thread when searching for “balena mount /lib/fimware rw” which is pretty close to the thread’s title… yet the thread didn’t quite answer the question. As I’ve found a bit more about the answer, I thought I would add it here. (Chances are I’ll need to search again in a few months’ time, so really I am helping myself.) :slight_smile:

Regarding the /lib/firmware folder, it is possible to “bind mount” it on an app container by setting the io.balena.features.firmware label in the docker-compose.yml file (or by using a single-container app with a single Dockerfile):

With that in place, firmware files can be added through an app container. The /lib/firmware folder will be initially mounted “read only” on the app container, but it can remounted “read write” before copying the file(s) with the command:

# on the app container
mount -o remount,rw /lib/firmware

It works similarly for the /lib/modules folder.

Specifically regarding network interfaces that are required to allow the device to connect to the internet, note that balena does not advise loading kernel modules or firmware files via app containers because of the risk that a routing application update could fail (e.g. a typo in the Dockerfile entry point script) and thus render the device unreachable. It would also make host OS upgrades riskier, in case the firmware file is incompatible (thought host OS upgrades should be first tested in a lab anyway…).