├── .github ├── ISSUE_TEMPLATE │ ├── bug_report.md │ └── feature_request.md ├── pull_request_template.md └── workflows │ └── repo_dispatch.yml ├── .gitignore ├── .gitmodules ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── COPYING ├── README.md ├── build └── conf │ ├── bblayers.conf │ ├── local.conf │ └── multiconfig │ ├── guest.conf │ ├── host-onie.conf │ └── host.conf ├── contrib ├── clone_mion_repos.sh └── update_mion_repos.sh ├── cronie.sh ├── licenses ├── CC-BY-4.0 └── MIT └── mc_build.sh /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: 'new' 6 | assignees: N-Mc-Nally 7 | 8 | --- 9 | 10 | **Describe the bug** 11 | A clear and concise description of what the bug is. 12 | 13 | **Expected behavior** 14 | A clear and concise description of what you expected to happen. 15 | 16 | **Steps To Reproduce** 17 | 1. ... 18 | 2. ... 19 | 20 | **Error logs / Screenshots** 21 | If applicable, add error logs or screenshots to help explain your problem. 22 | 23 | **System information (please complete the following information):** 24 | 25 | For build or compilation issues please provide: 26 | - Tagged release or specific commits for all repos used to build 27 | - OS version 28 | - Any other relevant version information 29 | 30 | For issues on a running switch please provide: 31 | - Tagged release or specific commits for all repos used to build 32 | - Hardware version - make/model/revision 33 | - ONIE version 34 | 35 | **If the issue is related to documentation please provide the following:** 36 | - A link to the specific page/document that needs to be addressed 37 | 38 | **Additional context** 39 | Add any other context about the problem here. 40 | 41 | Please @mention any relevant developers here. 42 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: 'new' 6 | assignees: N-Mc-Nally 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Describe alternatives you've considered** 17 | A clear and concise description of any alternative solutions or features you've considered. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the feature request here. 21 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | # repo: mion 2 | 3 | - Issue: #? 4 | 5 | - Affected hardware: ALL -or- _specific switches_ 6 | - Build command: cronie.sh ... 7 | - Tested on: _switch model_ 8 | 9 | - Description: _brief description of issue or enhancment_ 10 | -------------------------------------------------------------------------------- /.github/workflows/repo_dispatch.yml: -------------------------------------------------------------------------------- 1 | 2 | # Send a repo dispatch on pushes to the dunfell branch in order to trigger a build 3 | 4 | name: repo_dispatch 5 | 6 | on: 7 | push: 8 | branches: [ dunfell ] 9 | # pull_request: 10 | # branches: [ dunfell ] 11 | workflow_dispatch: 12 | 13 | jobs: 14 | dispatch: 15 | runs-on: self-hosted 16 | steps: 17 | - name: Dispatch on push to dunfell 18 | run: | 19 | curl -X POST https://api.github.com/repos/NetworkGradeLinux/mion-ci/dispatches \ 20 | -H "Accept: application/vnd.github.v3+json" \ 21 | -H "Authorization: token ${{ secrets.ACCESS_TOKEN }}" \ 22 | --data '{"event_type": "push", "client_payload": { "repository": "'"$GITHUB_REPOSITORY"'" }}' 23 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | /build/* 2 | !/build/conf 3 | /build/conf/* 4 | !/build/conf/bblayers.conf 5 | !/build/conf/local.conf 6 | !/build/conf/multiconfig 7 | *.log 8 | mion-*/ 9 | meta-mion*/ 10 | -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "bitbake"] 2 | path = bitbake 3 | url = git://git.openembedded.org/bitbake 4 | branch = 1.46 5 | [submodule "openembedded-core"] 6 | path = openembedded-core 7 | url = git://git.openembedded.org/openembedded-core 8 | branch = dunfell 9 | [submodule "meta-openembedded"] 10 | path = meta-openembedded 11 | url = git://git.openembedded.org/meta-openembedded 12 | branch = dunfell 13 | [submodule "meta-virtualization"] 14 | path = meta-virtualization 15 | url = https://git.yoctoproject.org/git/meta-virtualization 16 | branch = dunfell 17 | [submodule "meta-security"] 18 | path = meta-security 19 | url = https://git.yoctoproject.org/git/meta-security 20 | branch = dunfell 21 | [submodule "meta-yocto"] 22 | path = meta-yocto 23 | url = git://git.yoctoproject.org/meta-yocto 24 | branch = dunfell 25 | [submodule "meta-python2"] 26 | path = meta-python2 27 | url = https://git.openembedded.org/meta-python2 28 | branch = dunfell 29 | [submodule "meta-intel"] 30 | path = meta-intel 31 | url = https://git.yoctoproject.org/git/meta-intel 32 | branch = dunfell 33 | [submodule "meta-sca"] 34 | path = meta-sca 35 | url = https://github.com/priv-kweihmann/meta-sca.git 36 | branch = dunfell 37 | 38 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to make participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting and giving constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing compassion and kindness towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies within all project spaces, and it also applies when 49 | an individual is representing the project or its community in public spaces. 50 | Examples of representing a project or community include using an official 51 | project e-mail address, posting via an official social media account, or acting 52 | as an appointed representative at an online or offline event. Representation of 53 | a project may be further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at . All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 71 | version 1.4, available at 72 | 73 | [homepage]: 74 | 75 | For answers to common questions about this code of conduct, see 76 | 77 | 78 | ## Interpretation 79 | 80 | See our Interpretation of the Code of 81 | Conduct: [CoC-interpretation](https://docs.mion.io/Coc-interpretation.html) 82 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to Network Grade Linux 2 | 3 | Welcome to the Network Grade Linux (NGL) community! 4 | 5 | Here we cover some basics for how to get involved and contribute. There's 6 | also links to more in-depth information. 7 | 8 | If you're looking for a quick-start guide, it's in the [README](README.md). For 9 | more general documentation and to find out what the project is all about, head 10 | over to our documentation page at . 11 | 12 | We also have [our dev wiki](https://github.com/NetworkGradeLinux/mion-docs/wiki) 13 | with information related to mion development. 14 | 15 | Have Questions? What to get a sense of our growing community? Our Slack channel 16 | is . 17 | 18 | ## Table of Contents 19 | 20 | [Code of Conduct](#code-of-conduct) 21 | 22 | [Things to Know First](#things-to-know-first) 23 | 24 | [How to Contribute](#how-to-contribute) 25 | 26 | [Getting in Touch](#getting-in-touch) 27 | 28 | ## Code of Conduct 29 | 30 | All contributors are expected to read and agree to our [Code of Conduct](CODE_OF_CONDUCT.md) 31 | and our [interpretation](https://docs.mion.io/Coc-interpretation.html). By 32 | contributing to the project, you acknowledge that you agree to follow it. For 33 | questions regarding the Code of Conduct, please contact a maintainer or 34 | 35 | 36 | ## Things to know first 37 | 38 | While prerequisites will vary depending on what you plan on contributing, 39 | in general, you should know: 40 | 41 | * [The Yocto Project](https://docs.yoctoproject.org/) 42 | * [Introduction and overview](https://docs.yoctoproject.org/overview-manual/overview-manual-intro.html) 43 | * [Quick Build](https://docs.yoctoproject.org/brief-yoctoprojectqs/brief-yoctoprojectqs.html) 44 | 45 | * [Git Workflow](https://GitHub.com/NetworkGradeLinux/mion-docs/blob/dunfell/_meta/git_commandments.md) 46 | * [Yocto Project Git Workflow](https://docs.yoctoproject.org/overview-manual/overview-manual-development-environment.html#git-workflows-and-the-yocto-project) 47 | * [OpenEmbedded Commit Messages and Patches](http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines) 48 | 49 | ## How to Contribute 50 | 51 | Network Grade Linux(NGL) has a number of elements which make up the project. 52 | At the core of NGL is mion, the network operating system; an Embedded Linux 53 | distribution built by using the Yocto Project/OpenEmbedded. 54 | 55 | After identifying what and where you wish to contribute, become familiar with 56 | our workflow. Our workflow is largely the same across all the repositories, and 57 | is largely inline with The Yocto Project and OpenEmbedded. "Dunfell" is 58 | currently our default branch, which is where branches are merged into. 59 | 60 | You will also need to have a GitHub account. 61 | 62 | ### Project Components 63 | 64 | Here's an overview of our repositories: 65 | 66 | * [mion](https://GitHub.com/NetworkGradeLinux/mion); the main repository, where 67 | the build script, sub-modules, and 68 | [community contrib scripts](https://GitHub.com/NetworkGradeLinux/mion/tree/dunfell/contrib) 69 | can be found. 70 | * [meta-mion](https://GitHub.com/NetworkGradeLinux/meta-mion); the mion Yocto 71 | Project distro layer. Distro config and image recipes can be found here. 72 | * [meta-mion-bsp](https://GitHub.com/NetworkGradeLinux/meta-mion-bsp); board 73 | Support Layers, This is where you can find support for switch hardware, taking 74 | the form of `meta-mion-`. 75 | * [mion-docs](https://GitHub.com/NetworkGradeLinux/mion-docs); our main 76 | documentation source, where the pages on come from. 77 | Documentation is a great place to get started and gain practice with our 78 | workflow! 79 | * [meta-mion-sde](https://GitHub.com/NetworkGradeLinux/meta-mion-sde/); 80 | Recipes needed to enable switch ASIC functionality 81 | * [meta-mion-backports](https://GitHub.com/NetworkGradeLinux/meta-mion-backports/); 82 | Recipes backported from other Yocto project repos, such as K3s support 83 | * [meta-mion-unsupported](https://GitHub.com/NetworkGradeLinux/meta-mion-unsupported); 84 | layers which are not currently supported, such as `meta-mion-simplerunc` 85 | 86 | ### Bugs Reports & Feature Requests 87 | 88 | An overview of current issues and development tasks, from bugs to enhancements 89 | can be viewed at: . If 90 | you're interested in being assigned one of the existing issues, feel free to 91 | comment on the issue or get in touch with one of the maintainers. 92 | 93 | ### Git workflow 94 | 95 | We provide a **brief overview** on our workflow and key aspects below. 96 | 97 | To start, make sure that git is configured with your name and the email 98 | associated with your git account. Additionally, make sure that your GitHub 99 | account is set up to use 2FA. 100 | 101 | After cloning the repository you plan on contributing to, create a branch named 102 | `username/short-discription`. For example, if your username on GitHub is 103 | "pygmyshew" and you're updating information in a README: 104 | 105 | ```shell 106 | git checkout -b pygmyshew/update-README 107 | ``` 108 | 109 | #### Commits 110 | 111 | After making the changes, and you're ready to commit, you will want to include a 112 | "sign off" to help verify that it is you who is contributing. You can do so 113 | automatically by using the git `--signoff` option. It's also good practice to 114 | set up a GPG key on GitHub for signing your commit. After it's set up, you can 115 | use the `-S` option for git. 116 | 117 | ```shell 118 | git commit -S --signoff 119 | ``` 120 | 121 | This will open an editor where you type your commit message. Please read the 122 | information on git workflow under [Things to Know First](#things-to-know-first) 123 | for more in-depth guidelines for commit messages. In short, use the imperative 124 | in the first line to mention what your commit addresses. For example: "Update 125 | mion README for 2021.09 changes". After a blank newline, you can add more details 126 | on what you changed, but you should leave out the "how". After another newline, 127 | tag the issue number that the commit addresses or applies to. 128 | 129 | Push your branch: 130 | 131 | ```shell 132 | git push -u origin pygmyshew/update-README 133 | ``` 134 | 135 | If you've made multiple commits before being ready to open a pull request, you 136 | must use git rebase to squash/fixup all the commits into one. It's also good 137 | practice to `git pull` first to make sure your development branch is up to date 138 | and that there are no conflicts. 139 | 140 | ### Pull Requests 141 | 142 | After pushing your commit to the branch, you can put in a pull request. Make 143 | sure to tag and assign a maintainer for review of the pull request. After a pull 144 | request is approved and merged into the default branch, delete your development 145 | branch. Maintainers may request that you resubmit your pull request if it does 146 | not follow the guidelines. 147 | 148 | > When opening a pull request, most of our repos have templates asking for 149 | specific information and confirmation that you've taken the steps to verify the 150 | changes. 151 | 152 | ## Getting in Touch 153 | 154 | The best way to get in touch is by using our Slack channel: [Slack channel](https://networkgradelinux.slack.com). 155 | Due to differences in time zones and work loads, we may not be able to respond 156 | immediately, but will get back to you as soon as possible. Even if you don't 157 | have a question, feel free to join and chat! 158 | -------------------------------------------------------------------------------- /COPYING: -------------------------------------------------------------------------------- 1 | Copyright (C) 2016-2020, Togán Labs 2 | 3 | All content outside of the `docs` directory is distributed under the MIT License, 4 | see `licenses/MIT` for full text. 5 | 6 | Patches to upstream code are distributed under the License of the upstream project. 7 | 8 | All documentation source text in the `docs` directory is distributed under the 9 | Creative Commons Attribution 4.0 International License, see `licenses/CC-BY-4.0` 10 | for full text. 11 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # About mion 2 | 3 | mion is a Linux distro and image builder designed for operation in 4 | high-risk environments such as Critical National Infrastructure. mion is 5 | designed to run mainly on programmable network switches, although, due to it 6 | being based on the Yocto Project and OpenEmbedded, it is not limited to that 7 | use case. 8 | 9 | mion tracks the Yocto Project's dunfell and dunfell-next branches. Dunfell is 10 | the Yocto Project's 3.1 [Long Term Support](https://www.yoctoproject.org/yocto-project-long-term-support-announced/) 11 | branch. 12 | 13 | > mion is provided under a MIT License. See [COPYING](#copying) for copyright and 14 | license information. 15 | 16 | ## Quickstart 17 | 18 | Reference information for building mion. 19 | 20 | Getting familiar with the [Yocto Project and OpenEmbedded](https://www.yoctoproject.org/docs/). 21 | 22 | Want to know more about mion? Our [main documentation](https://docs.mion.io) 23 | has the in-depth information and resources to help get you started. 24 | 25 | ### Table of Contents 26 | 27 | [About](#about-mion) 28 | 29 | [Obtaining mion](#obtaining-mion-sources) 30 | 31 | [Basic Usage](#basic-usage) 32 | 33 | [Examples](#examples) 34 | 35 | ## Obtaining mion sources 36 | 37 | ```shell 38 | git clone --recursive https://github.com/NetworkGradeLinux/mion.git 39 | cd mion 40 | # To obtain related mion layers: 41 | git clone https://github.com/NetworkGradeLinux/meta-mion.git 42 | # Obtain the mion hardware layer 43 | git clone https://github.com/NetworkGradeLinux/meta-mion-bsp.git 44 | git clone https://github.com/NetworkGradeLinux/meta-mion-sde.git 45 | git clone https://github.com/NetworkGradeLinux/meta-mion-backports.git 46 | ``` 47 | 48 | ## Basic Usage 49 | 50 | To begin, set up the build environment using the OpenEmbedded init script. 51 | Afterwords you can use our build script. Running `../cronie.sh` without 52 | arguments displays basic usage. **In general:** 53 | 54 | ```shell 55 | source openembedded-core/oe-init-build-env 56 | ../cronie.sh -m 57 | ``` 58 | 59 | **NOTE: The \ argument must be provided last** 60 | 61 | To do a "dry run" without running a build, add `-e` which emits what would have 62 | run if you ran this from bitbake. 63 | 64 | If you are familiar with Yocto Project development and wish to 65 | use bitbake directly, see the local.conf for variables that need to be set. For 66 | running bitbake commands, including outside of building, such as 67 | `bitbake-layers show-layers`, run `../cronie.sh` as you otherwise would with 68 | the `-e` flag from the build directory and prepend the `BB_ENV_EXTRAWHITE` 69 | output to the bitbake command. 70 | 71 | Example: 72 | 73 | ```shell 74 | BB_ENV_EXTRAWHITE="ALL_PROXY BBPATH_EXTRA BB_LOGCONFIG BB_NO_NETWORK BB_NUMBER_THREADS BB_SETSCENE_ENFORCE BB_SRCREV_POLICY DISTRO FTPS_PROXY FTP_PROXY GIT_PROXY_COMMAND HTTPS_PROXY HTTP_PROXY MACHINE NO_PROXY PARALLEL_MAKE SCREENDIR SDKMACHINE SOCKS5_PASSWD SOCKS5_USER SSH_AGENT_PID SSH_AUTH_SOCK STAMPS_DIR TCLIBC TCMODE all_proxy ftp_proxy ftps_proxy http_proxy https_proxy no_proxy VENDOR" VENDOR="stordis" MACHINE="stordis-bf6064x-t" bitbake "mion-onie-image-onlpv1" 75 | ``` 76 | 77 | ### Example 78 | 79 | ```shell 80 | # Builds an ONLPV1 ONIE image 81 | ../cronie.sh -m stordis-bf2556x-1t mion-onie-image-onlpv1 82 | ``` 83 | -------------------------------------------------------------------------------- /build/conf/bblayers.conf: -------------------------------------------------------------------------------- 1 | # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf 2 | # changes incompatibly 3 | LCONF_VERSION = "7" 4 | 5 | BBPATH = "${TOPDIR}" 6 | BBFILES ?= "" 7 | 8 | MIONBASE = "${@os.path.abspath(os.path.join("${TOPDIR}", os.pardir))}" 9 | 10 | BBLAYERS = " \ 11 | ${MIONBASE}/openembedded-core/meta \ 12 | ${MIONBASE}/meta-openembedded/meta-oe \ 13 | ${MIONBASE}/meta-openembedded/meta-networking \ 14 | ${MIONBASE}/meta-openembedded/meta-python \ 15 | ${MIONBASE}/meta-openembedded/meta-filesystems \ 16 | ${MIONBASE}/meta-virtualization \ 17 | ${MIONBASE}/meta-security/meta-tpm \ 18 | ${MIONBASE}/meta-yocto/meta-yocto-bsp \ 19 | ${MIONBASE}/meta-sca \ 20 | ${MIONBASE}/meta-python2 \ 21 | ${MIONBASE}/meta-intel \ 22 | ${MIONBASE}/meta-mion \ 23 | ${MIONBASE}/meta-mion-bsp/meta-mion-${VENDOR} \ 24 | ${MIONBASE}/meta-mion-backports \ 25 | " 26 | -------------------------------------------------------------------------------- /build/conf/local.conf: -------------------------------------------------------------------------------- 1 | # 2 | # This file is your local configuration file and is where all local user settings 3 | # are placed. The comments in this file give some guide to the options a new user 4 | # to the system might want to change but pretty much any configuration option can 5 | # be set in this file. More adventurous users can look at local.conf.extended 6 | # which contains other examples of configuration which can be placed in this file 7 | # but new users likely won't need any of them initially. 8 | # 9 | # Lines starting with the '#' character are commented out and in some cases the 10 | # default values are provided as comments to show people example syntax. Enabling 11 | # the option is a question of removing the # character and making any change to the 12 | # variable as required. 13 | 14 | # 15 | # Machine Selection 16 | # 17 | # You need to select a specific machine to target the build with. There are a selection 18 | # of emulated machines available which can boot and run in the QEMU emulator: 19 | # 20 | #MACHINE ?= "qemuarm" 21 | #MACHINE ?= "qemuarm64" 22 | #MACHINE ?= "qemumips" 23 | #MACHINE ?= "qemumips64" 24 | #MACHINE ?= "qemuppc" 25 | #MACHINE ?= "qemux86" 26 | #MACHINE ?= "qemux86-64" 27 | # 28 | # This sets the default machine to be qemux86 if no other machine is selected: 29 | MACHINE ??= "qemux86" 30 | 31 | # 32 | # Where to place downloads 33 | # 34 | # During a first build the system will download many different source code tarballs 35 | # from various upstream projects. This can take a while, particularly if your network 36 | # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you 37 | # can preserve this directory to speed up this part of subsequent builds. This directory 38 | # is safe to share between multiple builds on the same machine too. 39 | # 40 | # The default is a downloads directory under TOPDIR which is the build directory. 41 | # 42 | #DL_DIR ?= "${TOPDIR}/downloads" 43 | 44 | # 45 | # Where to place shared-state files 46 | # 47 | # BitBake has the capability to accelerate builds based on previously built output. 48 | # This is done using "shared state" files which can be thought of as cache objects 49 | # and this option determines where those files are placed. 50 | # 51 | # You can wipe out TMPDIR leaving this directory intact and the build would regenerate 52 | # from these files if no changes were made to the configuration. If changes were made 53 | # to the configuration, only shared state files where the state was still valid would 54 | # be used (done using checksums). 55 | # 56 | # The default is a sstate-cache directory under TOPDIR. 57 | # 58 | #SSTATE_DIR ?= "${TOPDIR}/sstate-cache" 59 | 60 | # 61 | # Where to place the build output 62 | # 63 | # This option specifies where the bulk of the building work should be done and 64 | # where BitBake should place its temporary files and output. Keep in mind that 65 | # this includes the extraction and compilation of many applications and the toolchain 66 | # which can use Gigabytes of hard disk space. 67 | # 68 | # The default is a tmp directory under TOPDIR. 69 | # 70 | #TMPDIR = "${TOPDIR}/tmp" 71 | 72 | 73 | # 74 | # Package Management configuration 75 | # 76 | # This variable lists which packaging formats to enable. Multiple package backends 77 | # can be enabled at once and the first item listed in the variable will be used 78 | # to generate the root filesystems. 79 | # Options are: 80 | # - 'package_deb' for debian style deb files 81 | # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager) 82 | # - 'package_rpm' for rpm style packages 83 | # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk" 84 | # We default to ipk: 85 | PACKAGE_CLASSES ?= "package_ipk" 86 | PACKAGE_FEED_URIS = "http://tilde.toganlabs.com/repo" 87 | PACKAGE_FEED_BASE_PATHS = "${DISTRO_DATE}" 88 | 89 | # 90 | # SDK/ADT target architecture 91 | # 92 | # This variable specifies the architecture to build SDK/ADT items for and means 93 | # you can build the SDK packages for architectures other than the machine you are 94 | # running the build on (i.e. building i686 packages on an x86_64 host). 95 | # Supported values are i686 and x86_64 96 | SDKMACHINE ?= "x86_64" 97 | 98 | # 99 | # Extra image configuration defaults 100 | # 101 | # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated 102 | # images. Some of these options are added to certain image types automatically. The 103 | # variable can contain the following options: 104 | # "dbg-pkgs" - add -dbg packages for all installed packages 105 | # (adds symbol information for debugging/profiling) 106 | # "dev-pkgs" - add -dev packages for all installed packages 107 | # (useful if you want to develop against libs in the image) 108 | # "ptest-pkgs" - add -ptest packages for all ptest-enabled packages 109 | # (useful if you want to run the package test suites) 110 | # "tools-sdk" - add development tools (gcc, make, pkgconfig etc.) 111 | # "tools-debug" - add debugging tools (gdb, strace) 112 | # "eclipse-debug" - add Eclipse remote debugging support 113 | # "tools-profile" - add profiling tools (oprofile, lttng, valgrind) 114 | # "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.) 115 | # "debug-tweaks" - make an image suitable for development 116 | # e.g. ssh root access has a blank password 117 | # There are other application targets that can be used here too, see 118 | # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details. 119 | # We default to enabling the debugging tweaks. 120 | EXTRA_IMAGE_FEATURES = "debug-tweaks" 121 | 122 | # 123 | # Additional image features 124 | # 125 | # The following is a list of additional classes to use when building images which 126 | # enable extra features. Some available options which can be included in this variable 127 | # are: 128 | # - 'buildstats' collect build statistics 129 | # - 'image-mklibs' to reduce shared library files size for an image 130 | # - 'image-prelink' in order to prelink the filesystem image 131 | # - 'image-swab' to perform host system intrusion detection 132 | # NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink 133 | # NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended 134 | # image-prelink disabled for now due to issues with IFUNC symbol relocation 135 | USER_CLASSES ?= "buildstats image-mklibs" 136 | 137 | 138 | # 139 | # Runtime testing of images 140 | # 141 | # The build system can test booting virtual machine images under qemu (an emulator) 142 | # after any root filesystems are created and run tests against those images. To 143 | # enable this uncomment this line. See classes/testimage(-auto).bbclass for 144 | # further details. 145 | #TEST_IMAGE = "1" 146 | # 147 | # Interactive shell configuration 148 | # 149 | # Under certain circumstances the system may need input from you and to do this it 150 | # can launch an interactive shell. It needs to do this since the build is 151 | # multithreaded and needs to be able to handle the case where more than one parallel 152 | # process may require the user's attention. The default is iterate over the available 153 | # terminal types to find one that works. 154 | # 155 | # Examples of the occasions this may happen are when resolving patches which cannot 156 | # be applied, to use the devshell or the kernel menuconfig 157 | # 158 | # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none 159 | # Note: currently, Konsole support only works for KDE 3.x due to the way 160 | # newer Konsole versions behave 161 | #OE_TERMINAL = "auto" 162 | # By default disable interactive patch resolution (tasks will just fail instead): 163 | PATCHRESOLVE = "noop" 164 | 165 | # 166 | # Disk Space Monitoring during the build 167 | # 168 | # Monitor the disk space during the build. If there is less that 1GB of space or less 169 | # than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully 170 | # shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort 171 | # of the build. The reason for this is that running completely out of space can corrupt 172 | # files and damages the build in ways which may not be easily recoverable. 173 | # It's necesary to monitor /tmp, if there is no space left the build will fail 174 | # with very exotic errors. 175 | BB_DISKMON_DIRS = "\ 176 | STOPTASKS,${TMPDIR},1G,100K \ 177 | STOPTASKS,${DL_DIR},1G,100K \ 178 | STOPTASKS,${SSTATE_DIR},1G,100K \ 179 | STOPTASKS,/tmp,100M,100K \ 180 | ABORT,${TMPDIR},100M,1K \ 181 | ABORT,${DL_DIR},100M,1K \ 182 | ABORT,${SSTATE_DIR},100M,1K \ 183 | ABORT,/tmp,10M,1K" 184 | 185 | # 186 | # Shared-state files from other locations 187 | # 188 | # As mentioned above, shared state files are prebuilt cache data objects which can 189 | # used to accelerate build time. This variable can be used to configure the system 190 | # to search other mirror locations for these objects before it builds the data itself. 191 | # 192 | # This can be a filesystem directory, or a remote url such as http or ftp. These 193 | # would contain the sstate-cache results from previous builds (possibly from other 194 | # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the 195 | # cache locations to check for the shared objects. 196 | # NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH 197 | # at the end as shown in the examples below. This will be substituted with the 198 | # correct path within the directory structure. 199 | #SSTATE_MIRRORS ?= "\ 200 | #file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ 201 | #file://.* file:///some/local/dir/sstate/PATH" 202 | 203 | 204 | # 205 | # Qemu configuration 206 | # 207 | # By default qemu will build with a builtin VNC server where graphical output can be 208 | # seen. The two lines below enable the SDL backend too. By default libsdl-native will 209 | # be built, if you want to use your host's libSDL instead of the minimal libsdl built 210 | # by libsdl-native then uncomment the ASSUME_PROVIDED line below. 211 | #PACKAGECONFIG_append_pn-qemu-native = " sdl" 212 | #PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" 213 | #ASSUME_PROVIDED += "libsdl-native" 214 | 215 | # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to 216 | # track the version of this file when it was generated. This can safely be ignored if 217 | # this doesn't mean anything to you. 218 | CONF_VERSION = "1" 219 | DISTRO="mion" 220 | 221 | GLIBC_ADDONS = "nptl" 222 | 223 | # To include the ptests in the image, they need to be included as a distro 224 | # feature. 225 | # This should be done when building mion-image-onlpv1-ptest. 226 | 227 | #DISTRO_FEATURES_append += " ptest" 228 | 229 | # The following lines need to be set if you want to do mc builds using bitbake. 230 | # 231 | # If you want to pass in CONTAINER_NAMES CONTAINER DEPENDS BBMULTICONFIG 232 | # and MION_CONT_DISABLE you'll want to set BB_ENV_EXTRAWHITE either in local.conf 233 | # or on the command line 234 | # 235 | #BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CONTAINER_NAMES CONTAINER_DEPENDS BBMULTICONFIG MION_CONT_DISABLE" 236 | # 237 | # You'll want to set the container names that will be on the images. These will end 238 | # up in the default-guest recipe. 239 | # 240 | #CONTAINER_NAMES=" mion-guest-onlpv1 mion-guest-onlpv2" 241 | # 242 | # You need to set the CONTAINER_DEPENDS to the guest packaging image. These are nested 243 | # recipes for packaging up the guest container. They are stored in 244 | # meta-mion/meta-mion-simplerunc/recipes-core/mion-image-packaging/ 245 | #CONTAINER_DEPENDS=" mion-guest-onlpv1-pkg mion-guest-onlpv2-pkg" 246 | # 247 | # Switch machine name. Switch machines must be in this format - 248 | # 249 | #MACHINE="stordis-bf2556x-1t" 250 | # 251 | # Names of containers that should be disabled on boot. If this is not set, all 252 | # containers that are preinstalled and preconfigured on the host will autostart. 253 | # 254 | #MION_CONT_DISABLE="mion-guest-onlpv2" 255 | # 256 | # The arg line for VENDOR. This needs to be set to autodiscover vendor layers 257 | # 258 | # VENDOR="stordis" 259 | # 260 | # The following lines can be uncommented in order to build and install a signed bzImage 261 | # This requires UEFI Secure Boot to be enabled in the system BIOS and a Secure Boot version 262 | # of ONIE to be installed on the system. INSTALL_TYPE must be set to "initramfs" in the image. 263 | # 264 | #SECURE_BOOT_ENABLED = "true" 265 | #SECURE_BOOT_SIGNING_KEY = "" 266 | #SECURE_BOOT_SIGNING_CERT = "" 267 | -------------------------------------------------------------------------------- /build/conf/multiconfig/guest.conf: -------------------------------------------------------------------------------- 1 | TMPDIR = "${TOPDIR}/tmp-guest-${MACHINE}" 2 | 3 | # Capture compressed rootfs tar archives for all machines 4 | IMAGE_FSTYPES = "tar.xz" 5 | IMAGE_FILE_EXTENSION = "tar.xz" 6 | IMAGE_FEATURES = "" 7 | -------------------------------------------------------------------------------- /build/conf/multiconfig/host-onie.conf: -------------------------------------------------------------------------------- 1 | IMAGE_FILE_EXTENSION = "tar.xz" 2 | 3 | IMAGE_FSTYPES = " \ 4 | ${IMAGE_FILE_EXTENSION} \ 5 | ${IMAGE_FILE_EXTENSION}.bmap \ 6 | " 7 | 8 | -------------------------------------------------------------------------------- /build/conf/multiconfig/host.conf: -------------------------------------------------------------------------------- 1 | IMAGE_FSTYPES = " \ 2 | ext4 \ 3 | tar.bz2 \ 4 | " 5 | 6 | 7 | -------------------------------------------------------------------------------- /contrib/clone_mion_repos.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | set -e 3 | 4 | github_url="git@github.com:NetworkGradeLinux" 5 | 6 | repos=" 7 | meta-mion 8 | meta-mion-bsp 9 | meta-mion-backports 10 | meta-mion-sde 11 | mion-docs 12 | mion-testing 13 | " 14 | 15 | for r in $repos; do 16 | git clone "${github_url}/${r}.git" || exit 1 17 | echo 18 | done 19 | -------------------------------------------------------------------------------- /contrib/update_mion_repos.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | set -e 3 | 4 | # Sinple script to update all mion repos - must be run from the top level mion 5 | # repo and assumes that all repos are on the relevant branch 6 | 7 | repos=" 8 | meta-mion 9 | meta-mion-backports 10 | meta-mion-bsp 11 | meta-mion-sde 12 | mion-ci 13 | mion-docs 14 | mion-testing 15 | " 16 | 17 | printf "mion -> " && git rev-parse --abbrev-ref HEAD 18 | git pull || exit 1 19 | echo 20 | 21 | for r in $repos; do 22 | ( 23 | [ -d "$r" ] && cd "$r" 24 | printf "%s -> " "$r" && git rev-parse --abbrev-ref HEAD 25 | git pull --ff-only || exit 1 26 | echo 27 | ) 28 | done 29 | -------------------------------------------------------------------------------- /cronie.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # SPDX-License-Identifier: MIT 3 | set -e 4 | 5 | error() { echo "ERROR: $1" >&2; exit 1; } 6 | 7 | usage(){ 8 | cat <&2; exit 1; } 6 | 7 | info() { echo "INFO: $1"; } 8 | 9 | usage(){ 10 | cat <