-
Notifications
You must be signed in to change notification settings - Fork 19
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
Not able to use "hard" way to build firmware #105
Comments
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) |
ar71xx is the default, but if you pass a different architecture as the last
argument to `docker run` it will build that one instead
…On Tue, Apr 25, 2017 at 3:18 PM, gcgallo ***@***.***> wrote:
Think the problem is with entrypoint.sh. Will update to allow option for
building extender node, currently only provides option for ar71xx arch.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABDy8CC51SR51m_7um_OwCbt41LfKDGyks5rznExgaJpZM4NH-ml>
.
|
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 |
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, |
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: |
@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 think this is generally the right approach, although I think it's the
`make` part of the process that actually takes the longest, and if possible
we should find a way to cache most of that. We also want to make sure that
the seams in the build are well-though-out, so that the most common updates
(like e.g. tweaks to the babel config, or the dashboard) can make use of
most of the cache, and only rarer changes (like changing the OpenWRT
version) require a deeper rebuild of the cache.
…On Wed, Nov 8, 2017 at 7:45 AM, Jorrit Poelen ***@***.***> wrote:
Found #113 <#113> when
attempting a build and don't have access to network bandwidth. I think that
having a #111 <#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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABDy8CIcW00Vy_YYHD2I5RA0KwmNHVcrks5s0cyXgaJpZM4NH-ml>
.
|
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. |
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.
The text was updated successfully, but these errors were encountered: