Not able to use "hard" way to build firmware
paidforby opened this issue · 11 comments
Trying to build the extender node firmware using the old, hard way. The readme says I have to first build the home node firmware, unclear why, but when I try to do this it throws an "operation not permitted error" (see screenshot, probably dependencies, hence the docker container method). Is there a better more up-to-date way to build the extender node firmware, can we add this as an option in the "easy", docker method of building.
Looking at issue #103 it might have to do with my distro of ubuntu. I might try on my debian part, which had previously worked with the the old build script (but that may have been using docker?). Or I will just try running the extender node build script from within the same docker container I used to build the home node firmware. Hopefully the build scripts still point to the right directories since the extender node script needs to reference the home node build.
Think the problem is with entrypoint.sh. Will update to allow option for building extender node, currently only provides option for ar71xx arch. (this change should allow building from within docker)
Tried passing ar71xx.extender-node but it didn't like that. The extender nodes are weird because they aren't a different architecture, but require a different build script. Was going to add a condition that if you execute docker run -v $PWD/firmware_images:/firmware_images sudowrt ar71xx.extender-node it will point to the build_extender-node script instead, assuming that script works within docker.
Cannot run command posted in previous comment after running the home node build because the docker container where the build runs does not persist. To solve this I am trying to run both commands one after another in the same docker session like so,
docker run -v $PWD/firmware_images:/firmware_images sudowrt ar71xx; $PWD/firmware_images:/firmware_images sudowrt ar71xx.extender-node;
Assuming this works, we should come up with a better way of doing this so you don't have to rerun the entire build just to build the extender node. Maybe figure how to allow the docker container to persist? Or copy the necessary files out of the docker container after running the first build?
It seems the command I posted in the previous comment will not work because a docker container will not run multiple entrypoints without a supervisor. Instead, I plan on modifying the entrypoint so it can take multiple arguments and then loop through the build script for each argument. Should look something like this:
docker run -v $PWD/firmware_images:/firmware_images sudowrt ar71xx.home-node ar71xx.extender-node
@paidforby @andrewdollard I've boiled down entrypoint.sh to its essentials and removed the entrypoint_old.sh and just started a build. Hoping to report back in a bit.
Found #113 when attempting a build and don't have access to network bandwidth now, so having a hard time to reproduce/fix. I think that having a #111 would help to figure out how to build the firmware reliably. Perhaps we can break the process up into steps - (1) create a 14.04 based image with dependencies with push to docker hub, (2) create image and populate a pre-make image with all external deps ready to go (e.g., get repos, apply patches, import feeds). With image (2) pushed to docker hub, I imagine it might be easier to reproduce and make errors without having to download the entire interwebs each time. And, with some luck we'd be able to setup travis loops for (1) and (2).
Hoping to experiment with this soon and curious to hear thoughts.
I've documented a first pass at building firmware as discussed, see #111 (comment) . Please reproduce.
I was able to successfully build and run firmware (see #111 (comment)) . Please re-open if you can't reproduce.