Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create /resin-conf/lib/firmware/updates/ directory and bind mount it to /lib/firmware/updates/ #305

Open
floion opened this issue Sep 21, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@floion
Copy link
Collaborator

commented Sep 21, 2016

This is done so that the supervisor can then bind mount /lib/firmware/updates/ in the user container and users can use this read-write directory to put firmware files in it. (this is needed in the context of read-only root filesystem coupled with the fact that users may need additional firmware to add)

@floion floion added this to the 1.13 milestone Sep 21, 2016

@imrehg

This comment has been minimized.

Copy link
Contributor

commented Sep 21, 2016

(question because it's unclear for me at the moment)
Would this enable users adding new firmware through installing in the Dockerfile? In the current implementation of bind mount, app container firmware directory will be mounted over. So could not instal firmware in a RUN apt-get install <some-firmware-package>, but need to copy/install firmware in the startup script, run every time the container starts. This is not ideal. Also not ideal, that firmware copied are left around. It should live only as long as the application lives, imho.

@floion

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 21, 2016

apt-get'ing a firmware package where does it usually install the firmware into? Is it not into /lib/firmware?

@imrehg

This comment has been minimized.

Copy link
Contributor

commented Sep 21, 2016

@floion yes, it installs there. And currently that does not work, as the bind mount overrides/hides the contents of the container /lib/firmware with the host's bind mounted firmware directory.

See for example this BBGW firmware install (file from debian package): https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/install

@floion

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 22, 2016

There would be another way that would save us the copy and allow for apt-get'ing in the user container. We could have the supervisor start the user container with a volume (not a bind mounted host volume, just a regular volume) pointing at /usr/firmware/ in the container. Having this, we would have a corresponding folder in the host Os under /var/lib/docker/volumes/<some_sha>. From the host Os we could then use "docker inspect" to get the exact location and we could then use that to mount it over the host Os mountspace in /lib/firmware/updates/. In this the firmware an user downloads in the container is made available in the host OS for actual loading.
@petrosagg @imrehg any thoughts?

@floion

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 27, 2016

ping @petrosagg ?

@petrosagg

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2016

I don't think we can avoid copying the firmware at runtime because the kernel will attempt to load the firmware from the host mount namespace anyway. So even if we didn't shadow /lib/firmware in the container you'd still have a problem. So for now I think bind-mounting /lib/firmware/updates and letting the container copy files there is the best option

@telphan telphan removed their assignment May 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.