want mdb dmod bundles

Open
#4,449 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale

Research direction

Start by locating the CI build and host-image artifact paths that produce usr/lib/mdb and usr/lib/platform/*/lib/mdb. Determine how builds are identified with the value used to construct utsname, then define the archive and indexing flow for universally accessible storage such as catacomb; done means every customer- or machine-deliverable build has a retrievable module bundle without installing it on the machine.

Written by the indexing model from the issue text.

Description

build Debugging enhancement

I'm filing this here not because it's part of omicron but because there is a minority opinion that holds that omicron should be responsible for building and delivering host OS images, and this is where that lives. When it moves out to where it belongs, this can go with it.

Debugging crash dumps requires mdb modules that match the dump, not the machine on which debugging is being done. mdb supports loading alternate modules via a variety of arguments and commands, but we still need a way to look up the version and find the correct set of modules. This RFE covers building and delivering the modules (usr/lib/mdb and usr/lib/platform/*/lib/mdb) in a bundle -- a tarball is fine -- as a separate build artefact from all CI builds. That is: for any build that could conceivably ever be delivered to a customer or installed on an internal machine that's not a bench setup, this artefact needs to be available and indexed by the same identifier used to construct utsname. We should then archive all of these on catacomb or somewhere else that is universally accessible along with the dumps themselves. This artefact does not get delivered onto the machine itself.

Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oxidecomputer/omicron

All issues in oxidecomputer/omicron

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.