Stage the uploaded vmlinux on external-boot authority installs

Open
  • Is something wrong?
#3,123 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start with the cited members in src/kdive/providers/ports/external_boot.py (ExternalBootPlan, recovery points, state) and compare against how modules flow through src/kdive/providers/local_libvirt/lifecycle/boot/external_boot.py. Use the legacy staging at src/kdive/providers/local_libvirt/lifecycle/boot/guest_kernel_writer.py as the reference for placement at /usr/lib/debug/lib/modules/<release>/vmlinux, and read src/kdive/providers/shared/external_boot_bounds.py for the capacity accounting. Done when an authority install with a debuginfo_ref stages vmlinux under the same recovery rules and test_spine_live_script_over_the_wire passes; first read the #3121 option-A decision record it depends on.

Written by the indexing model from the issue text.

Description

area:debug area:provisioning effort:M priority:P1 provider:local-libvirt risk:daytime-only status:in-progress type:feature verification:ppc64le verification:x86

Part of #3121

Blocked by #3121 — the option-A decision record lands with the first #3121 change.

Problem

drgn-live on an uploaded kernel needs the Run's DWARF vmlinux (debuginfo_ref) inside the guest. ADR-0221 stages it only on the local-libvirt legacy install path. Installs that go through the external-boot provider authority publish the kernel, initrd and modules, but never the vmlinux. So drgn-live on an authority-installed kernel cannot resolve symbols, even when the operator uploaded vmlinux.

Evidence

  • src/kdive/providers/local_libvirt/lifecycle/boot/guest_kernel_writer.py:45,233-235,374-385 stages /usr/lib/debug/lib/modules/<ver>/vmlinux on the legacy path.
  • src/kdive/jobs/handlers/runs/install.py:106-107,162-172: with payload.authority_instance set, install only claims the step.
  • src/kdive/providers/ports/external_boot.py:175 (ExternalBootPlan), :155-184,259-262,328-343,438: the plan, recovery points and state carry kernel, initrd, modules and the recovery record, with no debuginfo field.
  • src/kdive/providers/local_libvirt/lifecycle/boot/external_boot.py:819-820,2000,2082,2515-2516 publishes modules only.
  • Bounds: src/kdive/providers/shared/external_boot_bounds.py:8-10, KDIVE_LIBVIRT_EXTERNAL_BOOT_CAPACITY_BYTES (src/kdive/providers/local_libvirt/settings.py:265-272, ADR-0602).

Expected

When a Run has a debuginfo_ref, an authority install places the matching vmlinux at /usr/lib/debug/lib/modules/<release>/vmlinux in the guest. The placement is covered by the same recovery and capacity rules as modules. It is proven by test_spine_live_script_over_the_wire on native ppc64le and x86_64 through the authority.

Proposed approach

Add an optional debuginfo member to the external-boot plan and the recovery state. Account its bytes in the external-boot capacity bound. Publish it with the same staged-then-rename pattern as modules. Follow the #3121 decision record.

Dominant language
Python
Stars
0
Forks
0
Avg merge
9h 13m
Merged PRs (30d)
197

Getting set up

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 randomparity/kdive

All issues in randomparity/kdive

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.