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.

Sign up for GitHub

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

Jump to bottom

build a build machine #111

Closed
paidforby opened this issue Oct 23, 2017 · 20 comments
Closed

build a build machine #111

paidforby opened this issue Oct 23, 2017 · 20 comments

Comments

@paidforby
Copy link

Recent difficulties and inconsistencies with our build process make me think it would be worth pursuing a streamlined, well-documented firmware build process. I'm interested to see what everyone thinks of this idea.
List of (potential) requirements:

  • consistent, easy-to-find hardware (raspberry pi? beagle bone?)
  • light-weight, minified *nix OS and interface.
  • open-source, infinitely-reproducible configuration
  • large, local, reliable, and resilient storage space (RAID setup?)
  • minimal need for internet access (local copies of necessary open wrt packages? IPFS integration?)
  • use as mythical "flashing station" also?
    Please add other requirements and suggestions in the comments.
@muxlux
Copy link
Contributor

muxlux commented Oct 23, 2017 via email

@paidforby
Copy link
Author

paidforby commented Oct 23, 2017 •
edited

@muxlux Not too often. Take between three and five hours, depending if you want to build both home node and extender node firmware (current method you have to build both to build for extender node). I don't think processing power should be an issue, i would be more concerned with network speed and storage space (I borked my Ubuntu partition by rebuilding this firmware a few too many times). There is always the Banana Pi or the Odroid if we need a little more juice.

@muxlux
Copy link
Contributor

muxlux commented Oct 23, 2017 via email

@Juul
Copy link
Member

Juul commented Oct 23, 2017

Making this all build on a non-x86 platform would likely be even more of a headache and it would be slow. Why not use virtualization? I'm no fan of docker but what about something simpler like vagrant? That's what I use for building other non-x86 stuff and it works great.

@paidforby
Copy link
Author

I'm all for making it virtual, but you'll always have a physical machine somewhere (unless we were to go the VPS route, but that raises different concerns). I've never used vagrant, but from my experiences with docker, virtual box, and hyper-v, i know that host system uptime, configuration, and resources are crucial. Sure we aren't pumping out firmware builds, but at the same time I don't want to tie up my computer's resources building firmware. A communal builds machine would open up the build process for more experimentation. We wouldn't want to make this the single source of all sudowrt firmware builds, so making it work on any machine is desirable, but this introduces possible host system variables.
@Juul I see your concern with ARM-based hardware, I'd be interested to explore possible x86 systems if there are any as common and accessible as equivalent ARM systems.

@andrewdollard
Copy link
Contributor

andrewdollard commented Oct 24, 2017 via email

@muxlux
Copy link
Contributor

muxlux commented Oct 24, 2017 via email

@jhpoelen
Copy link
Contributor

jhpoelen commented Nov 5, 2017

having a build server for the firmware sounds like a good idea. . . how far did we get on this? want to update my firmware on my home node, and trying to figure out whether to build my own firmware or pick an existing one.

jhpoelen pushed a commit that referenced this issue Nov 5, 2017
travis experiement related to #111
8d520eb
@jhpoelen jhpoelen mentioned this issue Nov 6, 2017
Closed
@muxlux
Copy link
Contributor

muxlux commented Nov 7, 2017 via email

@Juul
Copy link
Member

Juul commented Nov 7, 2017

I can put it on a computer that's always on. This is not an issue. Getting it actually working in a VM in a way that it can be set up on any (at least x86) computer without a bunch of hassle is the problem. I like vagrant over other systems for making it easy to build stuff because it is very very simple. It's literally just a vagrant script that configures the VM and a single bash script that does the one-time configuration. Take a look at this repo (never mind the huge readme).

@jhpoelen jhpoelen mentioned this issue Nov 8, 2017
Closed
@jhpoelen
Copy link
Contributor

jhpoelen commented Nov 15, 2017 •
edited

I've created a first pass at having travis push part of the firmware build machine image to docker hub, see .travis.yml. Also, see https://hub.docker.com/r/sudowrt/firmware .

so, now you can do docker pull sudowrt/firmware to pull latest firmware build machine image. Still not perfect, but able to re-use bandwidth provided by travis.

@jhpoelen
Copy link
Contributor

Did some more refactoring of the build scripts to separate grabbing of external resources (repos/feeds etc) from the actual building. Travis is happy, still attempting to do a full build. Please review build_lib / build_only / build / build_pre script if anyone gets around to it.

@jhpoelen
Copy link
Contributor

jhpoelen commented Nov 21, 2017 •
edited

Was able to create home node binaries using 13814cd in combination with travis / docker . Extender node failed because I ran out of disk space.

to reproduce:

  1. clone https://github.com/sudomesh/sudowrt-firmware
  2. docker pull sudowrt/firmware (pull build machine image created by travis from dockerhub)
  3. docker run -v $PWD/firmware_images:/firmware_images sudowrt/firmware (kick off make/build)
  4. inspect [sudowrt-firmware dir]/firmware_images

Here's the time stats just for building ar71xx home node -

real 107m1.262s
user 65m55.060s
sys 9m12.568s

@Juul
Copy link
Member

Juul commented Nov 21, 2017 via email

@paidforby
Copy link
Author

Work'd for me also.
The firmware is located in [sudowrt-firmware dir]/firmware_images/built_firmware/builder.ar71xx/bin/ar71xx and has n600 bin.

stats for home node:

real	124m35.957s
user	66m10.532s
sys	9m29.432s

stats for extender node:

real	37m30.702s
user	26m3.356s
sys	5m6.140s

Nicely done @jhpoelen

@jhpoelen
Copy link
Contributor

jhpoelen commented Nov 23, 2017 •
edited

Was just able to flash a MyNet N600 using firmware built using the travis/docker route and able to login through ssh (see below).

Now, hoping to resolve sudomesh/makenode#16 to confirm makenode works as usual.

$ ssh root@172.22.0.1
BusyBox v1.23.2 (2017-11-21 21:45:39 UTC) built-in shell (ash)


  ._______.___    ._______.______  ._____  .___    .___ .______  ._____  
  :_ ____/|   |   : .____/:_ _   \ :_ ___\ |   |   : __|:      \ :_ ___\ 
  |   _/  |   |   | : _/\ |   |   ||   |___|   |   | : ||       ||   |___
  |   |   |   |/\ |   /  \| . |   ||   /  ||   |/\ |   ||   |   ||   /  |
  |_. |   |   /  \|_.: __/|. ____/ |. __  ||   /  \|   ||___|   ||. __  |
    :/    |______/   :/    :/       :/ |. ||______/|___|    |___| :/ |. |
    :                      :        :   :/                        :   :/ 
                                        :                             : 
 -------------------------------------------------------------------------
 sudo mesh v0.2 (fledgling)
 UNCONFIGURED - see https://github.com/sudomesh/makenode
                for configurator. 

                              based on OpenWRT 15.05 (Chaos Calmer)
 -------------------------------------------------------------------------
 “When your rage is choking you, it is best to say nothing.” 
                                            - Octavia E. Butler, Fledgling
 -------------------------------------------------------------------------

@muxlux
Copy link
Contributor

muxlux commented Nov 23, 2017 via email

@jhpoelen
Copy link
Contributor

Last night, I was able to get an internet connection through ad-hoc mesh connections at sudoroom through n600 and n750 running a recently built firmware, resolving #105.

Reason for delay was my lack of understanding on how to troubleshoot a home node in addition to an exit node that needed some TLC.

Wishing I had an operator manual with general overview in addition to tips and tricks. This is why I created #118 .

So, it looks like the firmware built using the docker "build machine" functions as expected and we are one step closer to a fully automated build process.

@paidforby
Copy link
Author

To give an update:

I attempted to build the firmware on a raspberry pi, after changing the image requested in the Dockerfile to arm7/armhf-ubuntu, i was able to run the build process, though it did not appear to produce any binary images. More work needed if to run on arm arch.

I also attempted to run the build process on the communal machine in sudoroom; however, was unable to install docker-ce because there is no installation available for the distro running on that machine (Parrot/JollyRoger).

I am now setting up an old i5 laptop to put on the mesh as build service to be accessed by anyone with a mesh node, per bug 9 (sudomesh/bugs#9).

@paidforby paidforby mentioned this issue Mar 7, 2018
Closed
@eenblam eenblam mentioned this issue May 14, 2018
Open
17 tasks
paidforby pushed a commit that referenced this issue May 15, 2018
testing out auto_build idea related to #111
c90c7e2
paidforby pushed a commit that referenced this issue May 15, 2018
create create_build_machine script related to #111
6e495f5
@paidforby
Copy link
Author

I'm happy with the two-liner method I documented as the super-easy way. If anybody doesn't find this sufficient, feel free to reopen this issue.

@paidforby paidforby mentioned this issue Dec 15, 2019
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@Juul @jhpoelen @andrewdollard @muxlux @paidforby