Skip to content

fix(targets): restore librerouter naming and split into single-image + dual-tftp variants - #5

Merged
francoriba merged 2 commits into
mainfrom
fix/librerouter-target-naming-and-single-image
Sep 8, 2026
Merged

fix(targets): restore librerouter naming and split into single-image + dual-tftp variants#5
francoriba merged 2 commits into
mainfrom
fix/librerouter-target-naming-and-single-image

Conversation

@francoriba

@francoriba francoriba commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Problem

Two independent regressions made the librerouter target unusable in the mesh flow and any workflow that ships a self-contained initramfs kernel.

1. Naming mismatch with openwrt-tests/labnet.yaml

The base device in openwrt-tests labnet.yaml is librerouter_librerouter-v1 (renamed with a hyphen in openwrt-tests f3a08dc3 to match the OpenWrt firmware filename convention).

libremesh-tests's resolve_target_yaml in tests/lime_helpers.py uses that base device name to locate targets/<base_device>.yaml. Since commit 29a35a0 renamed the file to librerouter_v1.yaml, the mesh flow fails with:

FileNotFoundError: No target YAML found for place labgrid-fcefyn-librerouter_1
(instance: librerouter_1, base_device=librerouter_librerouter-v1)

The README.md and configs/firmware-catalog.yaml were already using the hyphen convention; only the file on disk was drifting.

2. Dual-TFTP hard-coded, breaks initramfs-kernel boot

The target YAML required both LG_IMAGE and LG_IMAGE_INITRD (kernel + rootfs uImage), which is only produced by ImageBuilder-based CI. Every other flow (LibreMesh releases, source builds, mesh tests, openwrt-tests healthcheck) ships a self-contained *-initramfs-kernel.bin and only sets LG_IMAGE, breaking with:

InvalidConfigError: configuration file '.../librerouter_librerouter-v1.yaml'
refers to unknown variable 'LG_IMAGE_INITRD'

Fix

  • Rename targets/librerouter_v1.yaml → targets/librerouter_librerouter-v1.yaml and rewrite it as the single-image default.
  • Preserve the previous dual-TFTP flow as targets/librerouter_librerouter-v1-dual-tftp.yaml for lime-packages CI.
  • Update README.md and docs/target-quirks.md with the two-variant table.

Follow-up

The lime-packages CI needs a small change to point LG_ENV at the -dual-tftp variant when lab_stage_firmware.sh runs in dual-TFTP mode.

@francoriba
fix(targets): restore librerouter naming and split into single-image …
381915f 
…+ dual-tftp variants

Two bugs made the LibreRouter unusable in the remote mesh flow:

1. **Naming mismatch**: commit 29a35a0 renamed
   `targets/librerouter_librerouter-v1.yaml` to `targets/librerouter_v1.yaml`,
   breaking the lookup done by `resolve_target_yaml` in mesh_boot_node.py
   which reads the base_device name from openwrt-tests' labnet.yaml
   (`librerouter_librerouter-v1`, renamed with hyphen in openwrt-tests
   commit f3a08dc to match the OpenWrt firmware naming convention).

2. **Dual-TFTP hard-coded**: the librerouter YAML required both LG_IMAGE
   and LG_IMAGE_INITRD, breaking any flow that ships a self-contained
   `*-initramfs-kernel.bin` (LibreMesh releases, source builds, mesh
   tests, openwrt-tests healthcheck).

Fix:

- Rename `librerouter_v1.yaml` back to `librerouter_librerouter-v1.yaml`
  and rewrite it as the **single-image default** (loads and boots one
  self-contained initramfs kernel). Matches openwrt-tests' variant and
  the reference in README.md / firmware-catalog.yaml.

- Preserve the previous dual-TFTP flow as
  `librerouter_librerouter-v1-dual-tftp.yaml` for pi-lime-packages /
  lime-packages CI, which uses ImageBuilder (cannot rebuild the kernel
  with CONFIG_INITRAMFS_SOURCE and therefore ships kernel.bin +
  rootfs.uimage separately).

- Update README.md and docs/target-quirks.md with the two-variant table
  and "when to use which" guidance.

The lime-packages CI needs a follow-up to point LG_ENV at the
`-dual-tftp` variant when `lab_stage_firmware.sh` runs in dual-TFTP
mode.
@francoriba francoriba mentioned this pull request Sep 8, 2026
Closed
@francoriba
chore(ci): cap ruff below 0.16 for reproducible lint
26ce471 
Ruff 0.16 enables additional default lint rules (RUF059, PIE810, ...)
that flag pre-existing patterns in the codebase, causing every new PR
to fail lint without any related code change. Cap the dev dependency
at <0.16 so CI runs are reproducible; bump this cap deliberately when
we opt into the new rules and fix the flagged patterns in a dedicated
cleanup pass.
@francoriba francoriba mentioned this pull request Sep 8, 2026
Merged
@francoriba
francoriba merged commit 3e04e0f into main Sep 8, 2026
3 checks passed
@francoriba
francoriba deleted the fix/librerouter-target-naming-and-single-image branch September 8, 2026 18:28
francoriba added a commit to fcefyn-testbed/lime-packages that referenced this pull request Sep 8, 2026
@francoriba
fix(ci): point LG_ENV at -dual-tftp target when staging kernel + ramdisk
054c982 
Follow-up to libremesh/libremesh-tests#5 which split the LibreRouter v1
target YAML into two variants:

- targets/librerouter_librerouter-v1.yaml           (single-image, default)
- targets/librerouter_librerouter-v1-dual-tftp.yaml (kernel + rootfs uImage)

The single-image variant is what mesh tests, LibreMesh releases and
openwrt-tests healthcheck actually use (initramfs-kernel.bin, only
LG_IMAGE set). The previous librerouter YAML required both LG_IMAGE and
LG_IMAGE_INITRD unconditionally, breaking every non-dual flow.

.github/workflows/build-firmware.yml pre-sets LG_ENV to
targets/${device}.yaml, which after the libremesh-tests split points at
the single-image variant. When lab_stage_firmware.sh detects the
dual-tftp payload (bin + uimage pair produced by build_image.sh for
devices like the LibreRouter v1 on ath79), it exports LG_IMAGE_INITRD
but the single-image YAML does not reference that variable, so labgrid
loads only the kernel and boot fails without a rootfs.

Override LG_ENV with the -dual-tftp sibling target file in the dual-TFTP
branch so labgrid resolves LG_IMAGE_INITRD and issues both TFTP loads.
No change for single-image devices (openwrt_one, linksys_e8450,
bananapi_bpi-r4, qemu_*): the else branch keeps the pre-set LG_ENV.
francoriba added a commit that referenced this pull request Sep 8, 2026
@francoriba
fix(targets): add librerouter_v1 short-name symlinks for lime-package…
47c046d 
…s CI

The librerouter has two device names across the testbed ecosystem:

- librerouter_v1              (short, OpenWrt ath79 profile name; used by
                               dut-config.yaml and pi-lime-packages
                               matrix.device / lab_stage_firmware.sh)
- librerouter_librerouter-v1  (long, <vendor>_<profile>; used by
                               openwrt-tests/labnet.yaml, labgrid place
                               names, and exporter YAML)

Commit 3e04e0f (PR #5) renamed the target YAML to the long form so
conftest_mesh.py::resolve_target_yaml() (which resolves via labnet.yaml)
finds it directly. That fix broke every short-form caller: pi-lime-packages
build-firmware.yml sets LG_ENV=targets/${matrix.device}.yaml =
targets/librerouter_v1.yaml, and lab_stage_firmware.sh derives
DUAL_ENV=targets/${DEVICE}-dual-tftp.yaml = targets/librerouter_v1-dual-tftp.yaml
(both missing after the rename), producing:

    NoConfigFoundError: configuration file
    'targets/librerouter_v1-dual-tftp.yaml' could not be found

Add symlinks so both naming conventions resolve to the same canonical
target file, without duplicating YAML content:

- targets/librerouter_v1.yaml           -> librerouter_librerouter-v1.yaml
- targets/librerouter_v1-dual-tftp.yaml -> librerouter_librerouter-v1-dual-tftp.yaml

Document the dual naming in docs/target-quirks.md and README.md so
future contributors don't remove the symlinks thinking they are stale.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@francoriba