# OpenBMC lists your board as supported and then warns you anyway

> OpenBMC is a Yocto based Linux distribution for baseboard management controllers, assembled from around thirty vendor layers and built by sourcing a setup script with your machine name. Its own README devotes more space to what support does not mean, from uneven port maturity to fans running at full throttle, and commits from non-members do not enter continuous integration automatically.

**openbmc/openbmc** — OpenBMC Distribution

- Repository: https://github.com/openbmc/openbmc
- Stars: 2,597 · Forks: 1,192
- Language: BitBake
- License: NOASSERTION
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/openbmc-openbmc

## A distribution of thirty layers, not an application

The repository root is a manifest of build layers rather than a program, and the naming tells you how it fits together.

There is a core `meta` layer, a `meta-phosphor` layer, a `meta-security` layer, an `upstream-layers/` directory, and then roughly thirty directories named `meta-<vendor>`. Among them: amd, ampere, aspeed, asrock, bytedance, delta, evb, facebook, fii, google, hpe, ibm, ieisystem, ingrasys, intel-openbmc, inventec, nuvoton, nvidia, nxp, openembedded, openpower, qualcomm, quanta, raspberrypi, supermicro, tyan, ufispace, wistron and yadro.

So a vendor ships its own layer, and building for that vendor's machine means building that layer's recipes. That is why the repository records its primary language as BitBake rather than as C or shell: the thing in this repository is the recipe set.

Four entries at the root do not fit the picture and are worth naming. `bitbake` is a directory, so the build tool itself is carried in the tree. `oe-init-build-env` and `openbmc-env` are two environment initialisers side by side, one from the OpenEmbedded world and one of its own. `.gitreview` and `.templateconf` are configuration files from an era when this kind of project was reviewed through Gerrit, which tells you the repository has outlived at least one hosting arrangement.

There is also an `eslint.config.js` at the root of a distribution built on Yocto, which is the JavaScript linter for the web interface sources somewhere in the layers.

## The setup script has to be sourced, not executed

This is the one mechanic in the README that trips up newcomers, and it explains why the instructions look unusual.

Any build requires an environment set up according to the hardware target. The script at the root of the repository is called `setup` and takes the name of the hardware target as an argument. It has to be sourced while you are in the top directory of the clone, and if you run it without arguments it prints the list of supported targets.

The signature it prints is:

```text
$ . setup <machine> [build_dir]
Target machine must be specified. Use one of:
...
```

The leading dot is the whole point. Sourcing runs the script inside your current shell so that the environment variables it sets stay there; executing it as a separate process would set them in a shell that immediately exits. The build directory is an optional second argument, which is how you keep two machine builds side by side.

Once you know the target, you source it with the machine name, and the example given is a single line:

```sh
. setup romulus
```

Running the script with no arguments is also the answer to the support question, because the target list it prints is the list of supported boards. The build itself is then one command:

```sh
bitbake obmc-phosphor-image
```

A longer list of supported machines lives in a documentation file under the phosphor layer, for cases where the printed list is not enough.

## The two prerequisite lists are not the same list

The prerequisite step points at the Yocto documentation for the current requirements and then gives two package lists, one per distribution family.

The Ubuntu one is:

```sh
sudo apt install git gcc g++ make file wget \
    gawk diffstat bzip2 cpio chrpath zstd lz4 bzip2
```

`bzip2` appears twice in that command, at the end of the second group and again at the end of the line.

The Fedora one is longer and has packages the Ubuntu one does not: python3, `which`, `hostname`, `diffutils` and `rpcgen`, along with `patch`. So the two lists are not the same list with different package managers in front of them, and a build host set up by copying the wrong one will fail somewhere in the dependency resolution rather than at a documented step.

The duplication is harmless, since a package manager will install a package named twice without complaint. The asymmetry is not, and it is not something the README explains, so the Yocto requirement page it points at is the authority and the lists here are a convenience.

That is the pattern across this README generally: it gives you the short path and links to the upstream documentation for the thing it does not want to keep current.

## Non-member commits do not enter continuous integration automatically

The testing section describes two levels of automated checking and one exception that tells you how the project is actually governed.

Commits submitted by members of the community are compiled and tested on a Jenkins server. They go through two levels: at the repository level a makefile directive named `make check` is run, and at the system level the commit is built into a firmware image and run with an arm-softmmu QEMU model against a battery of continuous integration tests.

The system-level test is the interesting one. Building a management controller image and booting it under emulation means the test is not a unit test with a mocked hardware layer, it is a real firmware image starting up. The emulation model named is the software floating point ARM target, which is a specific choice rather than a generic virtual machine.

Then the exception. Commits submitted by non-members do not automatically proceed through continuous integration testing. After a reviewer inspects the commit visually, a run can be performed manually by that reviewer.

So coverage depends on who you are. A member's change is built and booted without a human deciding to. A non-member's change waits for a person to read it and then choose to spend a run on it. The rest of the tooling is Robot Framework for all automation, with the test repository kept separately.

## Supported motherboard is not the same as supported system

The most useful section of the README is a question, and the answer is longer and more cautious than the feature list.

It starts from a scenario everybody has: will this run on my commercial off-the-shelf server board from a vendor such as Supermicro or ASRock. The answer is that you can see the list by running the setup script with no arguments, and that most supported platforms are specialized servers operated by companies running large datacenters, with some more generic commercial servers supported to varying degrees.

If your board is not in the list, it is not supported. And porting is described as a non-trivial undertaking, ideally done with schematics and documentation from the manufacturer. Reverse engineering is possible, the README says, but considerably more difficult and probably involving a greater risk of hardware damage.

Then the part that changes how you read the feature list, because being on the list is not enough. Two caveats are given.

The first is that ports are not equally mature, some platforms are better supported than others, and functionality on a supported board may be fairly limited.

The second is the one that bites in a datacentre. Support for a motherboard is not support for a complete system, and fan control in particular depends on the motherboard, on the fans connected to it, and on the chassis the two are housed in, all of which can vary dramatically between systems using the same board model. The example offered is unflattering and honest: your cooling fans may run continuously at full throttle.

So the list tells you the image will compile and install. It does not tell you the machine will behave.

## A shipped feature list, two items in progress, one still waiting

The feature section is organised in three buckets, and the buckets are the useful part.

What is there: host management for power, cooling, LEDs, inventory, events and watchdog; full IPMI 2.0 compliance with DCMI; code update support for multiple baseboard and BIOS images; a web-based user interface; REST interfaces; D-Bus based interfaces; serial-over-LAN over SSH; remote KVM; hardware simulation; automated testing; user management; and virtual media.

The IPMI line is the one to note if you are choosing between management controller implementations. It is a compliance claim, which means OpenBMC is an implementation of an existing specification rather than a competing interface, and it sits alongside the standards question rather than against it.

What is in progress: OpenCompute Redfish compliance and verified boot. Redfish is the modern replacement interface for the same job IPMI does, and it is listed as unfinished, which is the honest position for anyone whose tooling speaks Redfish and not IPMI.

What is requested but needs help: performance monitoring. That is the only entry in the third bucket, and it sits oddly next to cooling being a shipped feature. You can manage a fan, the README does not say, but you cannot get telemetry out of the machine.

Everything deeper is in a separate documentation repository rather than in this file.

## Two releases in the same minute, then a sixteen month gap

The release history has a shape worth noting.

Two point fourteen was published on 2023-05-16 at 21:21:20 and two point thirteen on the same date at 21:20:49, thirty-one seconds apart. Two point eighteen followed on 2025-05-30.

So two releases were cut from the same session, which is what happens when a stable branch is tagged alongside a maintenance line, and then the next numbered release came sixteen months later. There is nothing after that in the release list.

The last push to the repository was on 2026-10-02 and it is not archived, so work continues well past the newest tag. The badge at the top of the README points at a Jenkins job tracking the latest master build, which is continuous integration output rather than a release.

The repository records no licence in its metadata while carrying a LICENSE file at the root, so the terms are in the file and not in the header, and this article will not guess which licence it is. For an infrastructure project that vendors will build on, that is worth checking directly rather than inferring.

## Questions go to a forum, bugs go to issues

The support section routes different things to different places, and it is unusually firm about one of them.

For questions, the first instruction is to search the internet, on the grounds that the answer probably already exists. After that, general questions go to Stack Overflow under an openbmc tag, with an explicit warning to read a linked discussion about code licensing before posting any code. Technical discussions go to Discord or the mailing list instead.

Then the sentence that saves review time: please do not file an issue to ask a question, because the mailing list or Discord will be faster.

Bugs are the opposite. Issues on GitHub are the right place, with a recommendation to search existing issues first before opening a new one.

Contributions are routed through the contributing guidelines in the documentation repository, and there is an expectation attached rather than just a request: contributions are expected to contain test cases. Given that non-member changes do not enter continuous integration automatically, that expectation and the automation gap are two halves of the same arrangement.

The README also names a technical oversight forum at the end, and stops partway through describing it.

## Conclusion

Plan an OpenBMC port as hardware work rather than as a packaging exercise. The README is unusually clear that a board appearing in the supported list means the build targets it, not that the machine around it will behave, since fan control depends on the chassis and the fans as much as on the board. Three things to settle first. Whether you can get schematics from the board vendor, because the README calls a port without documentation considerably harder and not free of hardware risk. Whether your platform is already a layer in the tree, since around thirty vendors ship their own and yours may. And whether your contributions will actually be tested: members' commits go through the Jenkins pipeline automatically and non-members' do not, so plan to write the test cases yourself and expect a human to trigger the run.

## FAQ

### What is OpenBMC?

A Linux distribution for management controllers, the baseboard management controller used in devices such as servers, top of rack switches and RAID appliances. It is built with Yocto, OpenEmbedded, systemd and D-Bus so that a platform can be customised, and it implements IPMI 2.0 with DCMI compliance.

### what is openbmc used for

Host management of a server from outside it: power, cooling, LEDs, inventory, events and watchdog, plus a web interface, REST and D-Bus interfaces, serial over LAN, remote KVM, virtual media and code updates for multiple controller and BIOS images. Hardware simulation and automated testing are also part of the distribution.

### Does Supermicro use OpenBMC?

The repository carries a layer named for that vendor, alongside roughly thirty others including asrock, dell-style integrators such as inventec and tyan, and chip vendors such as intel-openbmc, nvidia and qualcomm. The README notes that most supported platforms are specialised servers run by companies operating large datacentres.

### how to install openbmc

Install the build host packages for your distribution, clone the repository, source the setup script with your machine name while in the top of the clone, then run bitbake obmc-phosphor-image. Running the setup script with no arguments prints the list of supported machines, and a second optional argument lets you keep a separate build directory.

### openbmc vs ipmi

They are not competitors. IPMI is the specification, and OpenBMC lists full IPMI 2.0 compliance with DCMI among its shipped features. The newer equivalent interface, OpenCompute Redfish, is listed under features in progress rather than as finished support.

### openbmc vs redfish

OpenBMC's shipped feature list covers IPMI 2.0 with DCMI compliance, while OpenCompute Redfish compliance appears under features in progress. So an IPMI client is the supported path today, and a Redfish client is not.

## Sources

- [Official README](https://github.com/openbmc/openbmc#readme)
- [Project repository](https://github.com/openbmc/openbmc)
- [Release notes](https://github.com/openbmc/openbmc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openbmc-openbmc