[RFC]: keep boot_check.sh without a NIC for now (STRICT-Q D2 residual) #103

Plan item: STRICT-Q

Preflight checks

• I searched existing issues, the roadmap, and current architecture documentation.
• I separated this proposal from unrelated cleanup or implementation work.

Proposal type

Developer tooling or test infrastructure

Affected subsystem

Build, CI, and tooling

Problem and use case

• scripts/gates/boot/boot_check.sh boots the guest with no network device. On this harness the seven network runtime cases therefore defer: net_ns_tx_isolation, netns_config_isolation, netns_rx_ingress, netns_rx_pool_lifecycle, netns_rx_eth0_slirp, netns_arp_probe_tx and netns_pending_frame.
• Under ZERO_OS_STRICT_TESTS=1, strict boot reports passed=29 deferred=36. Those seven deferrals come from the harness alone.
• Decision D2(a) of the STRICT-Q design (Zero-kernel/Nilix-docs-private#4, design/strict-q-deferral-inventory.md) listed boot_check.sh next to the three SMP harnesses.
• S2 (ci(smp): attach the restricted user network to the SMP harnesses (STRICT-Q S2) #102) applies D2(a) to smp_test.sh, smp_test_4core.sh and extended_smp_test.sh only. Whether to extend boot_check.sh was left as a separate decision.

Goals and non-goals

Decision (maintainer, 2026-11-11): boot_check.sh gets no NIC for now. This issue records that decision and what it leaves open.

Non-goals:

• Any change to boot_check.sh now.
• Re-deciding D2 for the SMP harnesses.

Proposed design

Nothing changes now. While the decision stands:

• Strict boot. It keeps the seven deferrals and cannot reach a strict pass, so STRICT-Q has to account for them some other way.
• Coverage. The same cases already run with the restricted user network:
  • on kernel_test.sh at 1 and 4 vCPUs;
  • after ci(smp): attach the restricted user network to the SMP harnesses (STRICT-Q S2) #102, on SMP-2, SMP-4 and the extended 8/16/32-vCPU harness.
• Regression test. scripts/tests/gate_log_test.py::test_runtime_harnesses_attach_the_restricted_user_network asserts that boot_check.sh does not pass the netdev arguments. That pins the current state.

Options when this is revisited:

1. Attach the NIC. Add the same -netdev user,id=net0,restrict=on,ipv6=off -device virtio-net-pci,netdev=net0,romfile= lines to boot_check.sh, as ci(smp): attach the restricted user network to the SMP harnesses (STRICT-Q S2) #102 does for the SMP harnesses. Then flip the test's expectation for boot_check.sh and re-measure the boot budget.
2. Account for the cases on the boot harness without a NIC. Record the seven cases as covered elsewhere for the boot harness through the declared-scope list (scripts/ci/strict_scope.txt, the S3 COVERED-BY batch), naming the gates above that run them.

Safety and trust-boundary analysis

None for the current state; nothing changes.

Option 1 gives the boot guest a restricted user-mode NIC, as kernel_test.sh and the SMP harnesses already have. restrict=on gives it no route to the host or the internet.

Alternatives considered

The two options above. Either is a separate change and a separate decision.

Verification plan

• Option 1. The test expectation flips for boot_check.sh. Strict boot should move from passed=29 deferred=36 to passed=36 deferred=29, with exactly the seven cases changing. Boot-gate times are compared with the parent.
• Option 2. The strict_scope_test checks extend to the new entries, and strict boot reports the seven cases as covered instead of deferred.

Implementation intent

I may implement this with maintainer guidance

Additional context

#64 (STRICT-Q), #102 (S2). Evidence for the SMP harnesses is in #102's .validation/strict-q-s2/README.md.