Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions distro/Dockerfile.bootable
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@
# link-native-cmake-x86_64 job uses; OVMX_LINK_NATIVE auto-detects ON only
# when `$CC -dumpmachine` reports an aarch64/x86_64 *-musl triple, which
# Ubuntu's musl-gcc wrapper does not.
FROM --platform=linux/amd64 alpine:3.20 AS link-native

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / VMS User Acceptance Test

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / R1 release e2e — media→menu install→separate container→login→PRODUCT SHOW (vms-37f)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SYSBOOT> authors cluster params (vms-46c gap

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install /DESTINATION -> boot the installed target -> login (vms-96ec)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / PARTS 0.2 Demo E2E (real boot, RMS load, DIRECTORY corroboration)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SCSNODE -> real hostname across reboot (vms-b6a7)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Persistent Boot Smoke Test

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Release-acceptance gate — boot the CUT artifact, verify shipped version (vms-a86f)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

Check warning on line 51 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install -> UPGRADE -> boot e2e (vms-f05)

FROM --platform flag should not use a constant value

FromPlatformFlagConstDisallowed: FROM --platform flag should not use constant value "linux/amd64" More info: https://docs.docker.com/go/dockerfile/rule/from-platform-flag-const-disallowed/

RUN apk add --no-cache cmake gcc g++ musl-dev binutils make linux-headers

Expand Down Expand Up @@ -633,11 +633,14 @@
# DECnet Phase IV: ship the NCP configuration utility on the running system
# so an admin can build the node database (DEFINE NODE) + set the executor.
# NCP.EXE is portable C and ships on BOTH arches (see the ovmx-images vax
# aggregate). The DECNETD.EXE network daemon is NOT staged yet: its AF_PACKET
# datalink + PTY login path need the netbsd-vax userspace port + a booted
# proof before it ships (rd vms-30e); staging it x86-only would be an unbuilt
# parity gap, which the #589 allowlist forbids. Plain `cp ... SYSEXE/` form so
# the image-parity scanner sees it.
# aggregate). DECNETD.EXE (staged above) is ALSO on all three rails now
# (rd vms-c1f): its raw-L2 datalink goes only through src/libdatalink's
# scs_datalink_* abstraction, which already ships both backends this
# facility needs -- AF_PACKET here and on Alpha (Linux-ABI), NetBSD bpf(4)
# on the VAX sysvol (tests/lab-vax/stage_sysvol.sh) -- so there was no
# unbuilt-parity gap to wait on; the earlier claim that DECNETD.EXE needed
# a netbsd-vax userspace port was a stale premise, corrected here. Plain
# `cp ... SYSEXE/` form so the image-parity scanner sees it.
cp build-static/bin/NCP.EXE /system-stage/vms/SYS0/SYSCOMMON/SYSEXE/ 2>/dev/null ; \
# TCC.EXE (compiler) + LINK.EXE (linker) -- the self-host toolchain on the
# shipped disk (vms-992e). LINK.EXE comes from build-static (BUILD_TOOLS
Expand Down Expand Up @@ -1036,8 +1039,8 @@
# (no --build-arg) stages nothing and boots with auth_group=0, byte-identical
# to today. Only a caller who explicitly names a real cluster's group (e.g.
# the lab VAX cluster's group 257) gets a CLUSTER_AUTHORIZE.DAT written.
ARG CLUSTER_AUTH_GROUP=0

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / VMS User Acceptance Test

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / R1 release e2e — media→menu install→separate container→login→PRODUCT SHOW (vms-37f)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SYSBOOT> authors cluster params (vms-46c gap

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install /DESTINATION -> boot the installed target -> login (vms-96ec)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / PARTS 0.2 Demo E2E (real boot, RMS load, DIRECTORY corroboration)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SCSNODE -> real hostname across reboot (vms-b6a7)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Persistent Boot Smoke Test

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Release-acceptance gate — boot the CUT artifact, verify shipped version (vms-a86f)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1042 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install -> UPGRADE -> boot e2e (vms-f05)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_GROUP") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/
ARG CLUSTER_AUTH_PASSWORD=""

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / VMS User Acceptance Test

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / R1 release e2e — media→menu install→separate container→login→PRODUCT SHOW (vms-37f)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SYSBOOT> authors cluster params (vms-46c gap

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install /DESTINATION -> boot the installed target -> login (vms-96ec)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / PARTS 0.2 Demo E2E (real boot, RMS load, DIRECTORY corroboration)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SCSNODE -> real hostname across reboot (vms-b6a7)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Persistent Boot Smoke Test

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Release-acceptance gate — boot the CUT artifact, verify shipped version (vms-a86f)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

Check warning on line 1043 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install -> UPGRADE -> boot e2e (vms-f05)

Sensitive data should not be used in the ARG or ENV commands

SecretsUsedInArgOrEnv: Do not use ARG or ENV instructions for sensitive data (ARG "CLUSTER_AUTH_PASSWORD") More info: https://docs.docker.com/go/dockerfile/rule/secrets-used-in-arg-or-env/

RUN mkdir -p /initramfs-slim/dev /initramfs-slim/proc /initramfs-slim/sys \
/initramfs-slim/tmp /initramfs-slim/var /initramfs-slim/mnt \
Expand Down Expand Up @@ -1249,7 +1252,7 @@
# boot.sh mounts a host directory at /data so the container owns the disk
# file and can write freely (avoids rootless Docker permission issues).
# When run standalone (no /data mount), falls back to /tmp/sysdisk.img.
CMD ARCH=$(uname -m) && \

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Alternate-disk boot — 2nd-disk device discovery reaches login (vms-9f5)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Console boot — no echoed-RETURN newline spam before Username: (vms-dec)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / VMS User Acceptance Test

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / R1 release e2e — media→menu install→separate container→login→PRODUCT SHOW (vms-37f)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SYSBOOT> authors cluster params (vms-46c gap

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install /DESTINATION -> boot the installed target -> login (vms-96ec)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / DCL/SHOW acceptance gate — boot, run the commands a user types, assert VMS-faithful output

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / PARTS 0.2 Demo E2E (real boot, RMS load, DIRECTORY corroboration)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / SCSNODE -> real hostname across reboot (vms-b6a7)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Persistent Boot Smoke Test

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / Release-acceptance gate — boot the CUT artifact, verify shipped version (vms-a86f)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/

Check warning on line 1255 in distro/Dockerfile.bootable

View workflow job for this annotation

GitHub Actions / install -> UPGRADE -> boot e2e (vms-f05)

JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals

JSONArgsRecommended: JSON arguments recommended for CMD to prevent unintended behavior related to OS signals More info: https://docs.docker.com/go/dockerfile/rule/json-args-recommended/
if [ "$ARCH" = "aarch64" ] || [ "$ARCH" = "arm64" ]; then \
QEMU=qemu-system-aarch64; \
MACHINE="-machine virt -cpu cortex-a57"; \
Expand Down
10 changes: 8 additions & 2 deletions tests/integration/test_sysvol_master_vax.sh
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,11 @@ make_image PROVISION.EXE P 15000
make_image LOGINOUT.EXE L 12000
make_image JOB_CONTROL.EXE J 11000
make_image STARTUP.EXE S 9000
# DECNETD.EXE (rd vms-c1f): stage_sysvol.sh's BOOT_IMAGES now includes it --
# the DCL acceptance battery's DECnet CTERM section hard-gates on it being on
# the VAX sysvol, so a stand-in is required here too or stage_sysvol.sh dies
# "boot image missing from images dir".
make_image DECNETD.EXE N 8000

# ---------------------------------------------------------------------------
# 2. Stage the system tree, then master a 32 MB volume from it.
Expand Down Expand Up @@ -100,14 +105,15 @@ echo "PASS: staged system tree round-trips master -> extract byte-exact"
# ---------------------------------------------------------------------------
ROOTED="SYS0/SYSCOMMON/SYSEXE"
for f in DCL.EXE PROVISION.EXE LOGINOUT.EXE JOB_CONTROL.EXE STARTUP.EXE \
SYSUAF.DAT RIGHTSLIST.DAT OVMXVMSSYS.PAR; do
DECNETD.EXE SYSUAF.DAT RIGHTSLIST.DAT OVMXVMSSYS.PAR; do
[ -f "$OUT/$ROOTED/$f" ] || fail "boot file absent from rooted SYSEXE after round-trip: $ROOTED/$f"
done
cmp -s "$IMAGES/DCL.EXE" "$OUT/$ROOTED/DCL.EXE" || fail "DCL.EXE not byte-exact at rooted path"
cmp -s "$IMAGES/PROVISION.EXE" "$OUT/$ROOTED/PROVISION.EXE" || fail "PROVISION.EXE not byte-exact at rooted path"
cmp -s "$IMAGES/DECNETD.EXE" "$OUT/$ROOTED/DECNETD.EXE" || fail "DECNETD.EXE not byte-exact at rooted path"
cmp -s "$REPO/distro/rootfs/vms/$ROOTED/SYSUAF.DAT" "$OUT/$ROOTED/SYSUAF.DAT" \
|| fail "SYSUAF.DAT not reused byte-exact"
echo "PASS: DCL.EXE + PROVISION.EXE + SYSUAF.DAT present + byte-exact at rooted [SYS0.SYSCOMMON.SYSEXE]"
echo "PASS: DCL.EXE + PROVISION.EXE + DECNETD.EXE + SYSUAF.DAT present + byte-exact at rooted [SYS0.SYSCOMMON.SYSEXE]"

# The mastered layout must be ROOTED, never flat: a flat [SYSEXE]DCL.EXE (i.e.
# SYSEXE directly under the MFD) is the exact shape that halts %OVMX-F-SYSINIT.
Expand Down
41 changes: 35 additions & 6 deletions tests/lab-vax/run-boot.sh
Original file line number Diff line number Diff line change
Expand Up @@ -267,13 +267,23 @@ master_volume() {
# and collect them by name into SYSVOL_IMAGES_DIR. build-boot-images-vax.sh
# already builds + Decision-A-activation-asserts all five; here we just copy
# the delivered images up. Cached.
#
# PLUS DECNETD.EXE (rd vms-c1f): the DCL acceptance battery's DECnet CTERM
# section hard-gates on this runtime, so the image it drives
# (SYS$SYSTEM:DECNETD.EXE) must actually be on the volume this staging feeds
# (stage_sysvol.sh -> master_system_volume). Built with a narrow `cmake
# --build --target decnetd_exe' (not the full ovmx-images aggregate
# build_vax_images() below already proves elsewhere) so this stays a cheap
# single-image add to the sysvol/acceptance boot path, same toolchain file
# tools/cross-vax/build-ovmx-images-vax-cmake.sh uses.
build_boot_image_set() {
if [ "${FORCE_SYSVOL_BUILD:-0}" != "1" ] \
&& [ -f "${SYSVOL_IMAGES_DIR}/DCL.EXE" ] \
&& [ -f "${SYSVOL_IMAGES_DIR}/PROVISION.EXE" ] \
&& [ -f "${SYSVOL_IMAGES_DIR}/LOGINOUT.EXE" ] \
&& [ -f "${SYSVOL_IMAGES_DIR}/JOB_CONTROL.EXE" ] \
&& [ -f "${SYSVOL_IMAGES_DIR}/STARTUP.EXE" ]; then
&& [ -f "${SYSVOL_IMAGES_DIR}/STARTUP.EXE" ] \
&& [ -f "${SYSVOL_IMAGES_DIR}/DECNETD.EXE" ]; then
log "boot image set present -- NOT rebuilding (set FORCE_SYSVOL_BUILD=1 to force)"; return 0; fi
mkdir -p "${SYSVOL_IMAGES_DIR}"
log "cross-building the full boot image set (STARTUP/PROVISION/DCL/JOB_CONTROL/LOGINOUT) for elf32-vax"
Expand All @@ -289,10 +299,20 @@ build_boot_image_set() {
for img in STARTUP.EXE PROVISION.EXE DCL.EXE JOB_CONTROL.EXE LOGINOUT.EXE; do
[ -f "${SYSVOL_IMAGES_DIR}/${img}" ] || die "boot image set missing ${img}"
done
log "cross-building DECNETD.EXE for elf32-vax (rd vms-c1f, cmake --target decnetd_exe)"
docker run --rm -v "${REPO}:/src" -w /src -v "${SYSVOL_IMAGES_DIR}:/out" \
--entrypoint sh "${CROSS_IMAGE}" -c '
set -e
cmake -S /src -B /tmp/build-decnetd-vax \
-DCMAKE_TOOLCHAIN_FILE=/src/tools/cross-vax/toolchain-vax-netbsd.cmake \
-DCMAKE_BUILD_TYPE=Release >/tmp/build-decnetd-vax-configure.log 2>&1
cmake --build /tmp/build-decnetd-vax --target decnetd_exe -- -j"$(nproc)" >/tmp/build-decnetd-vax-build.log 2>&1
cp /tmp/build-decnetd-vax/bin/DECNETD.EXE /out/DECNETD.EXE'
[ -f "${SYSVOL_IMAGES_DIR}/DECNETD.EXE" ] || die "DECNETD.EXE cross-build did not produce an elf32-vax image (rd vms-c1f)"
}

# 3c (sysboot). Master the OVMX SYSTEM volume: build the host vmsfs_master, stage
# the rooted [SYS0.SYSCOMMON] tree (stage_sysvol.sh: the five vax images +
# the rooted [SYS0.SYSCOMMON] tree (stage_sysvol.sh: the six vax images +
# reused data/COM files + the Decision-A SYSTARTUP_VMS.COM), and master a
# 64 MB vmsfs volume. All inside CROSS_IMAGE's native cc (same "cc a host tool
# in the container" pattern as master_volume above -- nothing on the host).
Expand Down Expand Up @@ -337,9 +357,13 @@ master_system_volume() {
# Hard content gate: the mastered volume MUST carry the images PID 1 execs and
# the SYSGEN params it reads, so a staging/caching regression fails HERE (red),
# never as a lenient boot that halts before PROVISION runs (rd vms-72da).
for f in DCL.EXE PROVISION.EXE OVMXVMSSYS.PAR; do
# DECNETD.EXE (rd vms-c1f) is in the same gate: the DCL acceptance battery's
# DECnet CTERM section hard-gates on it, so a regression that drops it off
# this rail's runtime must fail HERE too, not surface as a silent skip deep
# in the battery.
for f in DCL.EXE PROVISION.EXE OVMXVMSSYS.PAR DECNETD.EXE; do
echo "${listing}" | grep -qiF "${f}" \
|| die "mastered system volume is MISSING ${f} -- staging/caching regression (vms-72da)"
|| die "mastered system volume is MISSING ${f} -- staging/caching regression (vms-72da / vms-c1f)"
done
# vms-329: [USERS] must be on the volume or PROVISION's home-directory pass has
# no parent to create the four account homes in, and reports four
Expand All @@ -359,8 +383,13 @@ master_system_volume() {
# into VAX_IMAGES_DIR. These are REAL elf32-vax executables (the script asserts
# the Decision-A activation contract on each), NOT stand-ins -- both the OS kit
# and the distribution volume below draw from here (rd vms-d0e5 rung G).
# DECNETD.EXE (rd vms-c1f) joins the collected set: the aggregate already
# builds it (build-ovmx-images-vax-cmake.sh), and stage_sysvol.sh's
# BOOT_IMAGES now requires it in IMAGES_DIR -- the distribution volume
# below stages via stage_sysvol.sh --distribution from VAX_IMAGES_DIR, so
# without this the install mode would die "boot image missing".
build_vax_images() {
local need="STARTUP.EXE PROVISION.EXE DCL.EXE JOB_CONTROL.EXE LOGINOUT.EXE PRODUCT.EXE AUTHORIZE.EXE INITIALIZE.EXE SYSGEN.EXE"
local need="STARTUP.EXE PROVISION.EXE DCL.EXE JOB_CONTROL.EXE LOGINOUT.EXE PRODUCT.EXE AUTHORIZE.EXE INITIALIZE.EXE SYSGEN.EXE DECNETD.EXE"
if [ "${FORCE_VAX_IMAGES:-0}" != "1" ]; then
local have=1
for img in $need; do [ -f "${VAX_IMAGES_DIR}/${img}" ] || have=0; done
Expand All @@ -376,7 +405,7 @@ build_vax_images() {
set -e
BUILD_DIR=/tmp/build-vax-images-cmake sh tools/cross-vax/build-ovmx-images-vax-cmake.sh
for img in STARTUP.EXE PROVISION.EXE DCL.EXE JOB_CONTROL.EXE LOGINOUT.EXE \
PRODUCT.EXE AUTHORIZE.EXE INITIALIZE.EXE SYSGEN.EXE; do
PRODUCT.EXE AUTHORIZE.EXE INITIALIZE.EXE SYSGEN.EXE DECNETD.EXE; do
cp /tmp/build-vax-images-cmake/bin/$img /out/$img
done'
rc=$?; set -e
Expand Down
14 changes: 10 additions & 4 deletions tests/lab-vax/stage_sysvol.sh
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,12 @@
# STARTUP.EXE the PID-1 image (also installed as /sbin/init off-disk;
# present here so the SYSEXE tree matches an installed
# volume)
# DECNETD.EXE the DECnet Phase IV endnode (rd vms-c1f/vms-f40); the
# image the shared DCL/SHOW acceptance battery's DECnet
# CTERM section (--cterm-accept-test) hard-gates against
# on this rail. Shipped, not started: no startup
# procedure runs it. Its datalink is
# src/libdatalink's NetBSD bpf(4) backend.
# SYSUAF.DAT account database (binary $UAFDEF indexed Files-11 file;
# arch-neutral by construction -- the LE codec serializes
# every on-disk field via le16/le32/le64 over uint8[] byte
Expand All @@ -38,7 +44,7 @@
# SYS0/SYSCOMMON/SYSHLP/ HELPLIB.HLP (reused)
# SYS0/SYSCOMMON/SYSUPD/ PARTS_SETUP.COM (reused)
#
# Everything except the five .EXE images and SYSTARTUP_VMS.COM is copied
# Everything except the six .EXE images and SYSTARTUP_VMS.COM is copied
# VERBATIM from distro/rootfs/vms -- those files are architecture-independent
# data/DCL (INV-DRIFT: one source of truth, no vax fork of the data).
#
Expand Down Expand Up @@ -70,8 +76,8 @@
#
# Usage: stage_sysvol.sh [--distribution --kit <OVMX-OS-VAX.KIT>] \
# <images-dir> <repo-root> <stage-out-dir>
# <images-dir> must contain the five ELF32-vax boot images by name:
# DCL.EXE PROVISION.EXE LOGINOUT.EXE JOB_CONTROL.EXE STARTUP.EXE
# <images-dir> must contain the six ELF32-vax boot images by name:
# DCL.EXE PROVISION.EXE LOGINOUT.EXE JOB_CONTROL.EXE STARTUP.EXE DECNETD.EXE
# --distribution stage the installer-media shape (see above)
# --kit <file> path to the pre-built OVMX-OS-VAX.KIT to lay at
# SYS$UPDATE: (REQUIRED with --distribution; the kit
Expand Down Expand Up @@ -100,7 +106,7 @@ STAGE="${3:?usage: $0 [--distribution --kit <kit>] <images-dir> <repo-root> <sta
ROOTFS="$REPO/distro/rootfs/vms"
VAX_SYSTARTUP="$REPO/distro/rootfs-vax/vms/SYS0/SYSCOMMON/SYSMGR/SYSTARTUP_VMS.COM"
VAX_DISTRIB_SYSTARTUP="$REPO/distro/rootfs-distrib-only-vax/vms/SYS0/SYSCOMMON/SYSMGR/SYSTARTUP_VMS.COM"
BOOT_IMAGES="DCL.EXE PROVISION.EXE LOGINOUT.EXE JOB_CONTROL.EXE STARTUP.EXE"
BOOT_IMAGES="DCL.EXE PROVISION.EXE LOGINOUT.EXE JOB_CONTROL.EXE STARTUP.EXE DECNETD.EXE"
KIT_DEST_NAME="OVMX-OS-VAX.KIT"

die() { echo "[stage_sysvol] FATAL: $*" >&2; exit 1; }
Expand Down
36 changes: 21 additions & 15 deletions tests/qemu/lib/dcl_acceptance_battery.sh
Original file line number Diff line number Diff line change
Expand Up @@ -984,22 +984,21 @@ run_dcl_acceptance_battery() {
# IT IS RUN AS A FOREIGN COMMAND because DCL's RUN passes no arguments; that
# is the VMS way to pass one, not a shell escape.
#
# WHERE IT IS A HARD GATE, AND WHERE IT IS A REPORTED GAP. DECNETD.EXE is in
# the x86_64 shipped image set (distro/Dockerfile.bootable) and in the
# `ovmx-images` CMake aggregate, so it is built for vax as well -- but the
# VAX rail boots a FIVE-IMAGE sysvol (tests/lab-vax/stage_sysvol.sh:
# DCL/PROVISION/LOGINOUT/JOB_CONTROL/STARTUP) and the Alpha boot image has
# its own list, so neither carries it yet. Staging it on those two rails is
# tracked follow-on work, NOT something to fake here. So: where the image is
# PRESENT this is a hard gate on every assertion; where it is ABSENT the
# section reports a LOUD note naming the gap and asserts nothing -- the same
# "tracked + routed, never silently green" shape golden_diff_report uses.
# The one thing it must never do is pass because nothing ran.
# HARD GATE ON ALL THREE RAILS (rd vms-c1f). DECNETD.EXE is in the x86_64
# shipped image set (distro/Dockerfile.bootable), the VAX sysvol
# (tests/lab-vax/stage_sysvol.sh) and the Alpha boot image
# (tools/cross-alpha/build-alpha-bootimage.sh) -- every runtime this
# battery drives ships the image, so the "not on this runtime" note path
# below is UNREACHABLE in normal operation. It stays as a HARD FAILURE,
# not a note: if a staging regression ever drops DECNETD.EXE off a rail's
# runtime again, that is a real INV-6 hole (a shipped facility whose
# runtime cannot prove it) and must RED here, not silently pass because
# nothing ran.
local CTERM_OFF; CTERM_OFF=$(wc -c <"$LOG")
run_cmd 'DNETACC :== $SYS$SYSTEM:DECNETD.EXE'
send 'DNETACC --cterm-accept-test'
if wait_for 'IVIMAGE' 15 "$CTERM_OFF"; then
note "CTERM [vms-f40]: SYS\$SYSTEM:DECNETD.EXE is not on THIS runtime's system disk, so the inbound-SET-HOST authentication proof DID NOT RUN here (it is a hard gate on the rails that ship the image). Staging DECNETD.EXE into the VAX sysvol + the Alpha boot image is tracked follow-on work"
bad "CTERM [vms-f40]: SYS\$SYSTEM:DECNETD.EXE is not on THIS runtime's system disk, so the inbound-SET-HOST authentication proof DID NOT RUN (rd vms-c1f staged DECNETD.EXE onto every rail's runtime -- its absence here is a staging regression, not an expected gap)"
elif wait_for 'DECNETD-CTERM-ACCEPT:' 180 "$CTERM_OFF"; then
local CTSEG; CTSEG=$(tail -c "+$((CTERM_OFF + 1))" "$LOG" | tr -d '\r')
must_have "$CTSEG" 'DECNETD-CTERM-ACCEPT: PASS' \
Expand All @@ -1018,19 +1017,26 @@ run_dcl_acceptance_battery() {
fi
wait_for '$ ' 20 "$CTERM_OFF"

# SCOPE NOTE (rd vms-c1f): FAL's own auth proof (--fal-accept-test, rd
# vms-8c2/#1096) is NOT yet in this battery -- #1096 had not merged as of
# this section's hard-gate flip. DECNETD.EXE is now staged on all three
# rails, so once #1096 lands a FAL section here needs no rail-staging work
# of its own -- follow the SAME shape as CTERM above (assert on the verdict
# line, IVIMAGE means a real staging regression, never a silent note).

# =======================================================================
# DECnet NETACP ISOLATION (vms-9ab, P5) -- the A2/A8 security seam. Design
# vms-515 §3.4: attacker-controlled wire parsing runs at LOW privilege and
# hands NETACP's thin privileged control path only a VALIDATED, TYPED
# descriptor; the privileged path parses no attacker bytes. This mode is the
# NEGATIVE proof of that seam and needs NEITHER /dev/vms NOR CAP_NET_RAW --
# every case is refused at NETACP's privileged front door BEFORE it would
# mint a device or create a process. So unlike --cterm-accept-test it is a
# hard gate wherever DECNETD.EXE is present, executive or not.
# mint a device or create a process, so it never depended on an executive
# either way. Hard gate on all three rails (rd vms-c1f), same as CTERM above.
local ISOL_OFF; ISOL_OFF=$(wc -c <"$LOG")
send 'DNETACC --isolation-test'
if wait_for 'IVIMAGE' 15 "$ISOL_OFF"; then
note "NETACP isolation [vms-9ab]: SYS\$SYSTEM:DECNETD.EXE is not on THIS runtime's system disk, so the A2/A8 privileged-path isolation proof DID NOT RUN here (staging DECNETD.EXE onto the VAX/Alpha rails is the same tracked follow-on as CTERM above)"
bad "NETACP isolation [vms-9ab]: SYS\$SYSTEM:DECNETD.EXE is not on THIS runtime's system disk, so the A2/A8 privileged-path isolation proof DID NOT RUN (rd vms-c1f staged DECNETD.EXE onto every rail's runtime -- its absence here is a staging regression, not an expected gap)"
elif wait_for 'DECNETD-ISOLATION:' 60 "$ISOL_OFF"; then
local ISSEG; ISSEG=$(tail -c "+$((ISOL_OFF + 1))" "$LOG" | tr -d '\r')
must_have "$ISSEG" 'DECNETD-ISOLATION: PASS' \
Expand Down
14 changes: 12 additions & 2 deletions tools/cross-alpha/build-alpha-bootimage.sh
Original file line number Diff line number Diff line change
Expand Up @@ -174,10 +174,17 @@ docker run --rm --memory=8g --cpus="$(nproc)" \
# Core boot + login chain images (all EM_ALPHA static EXEC -- the Alpha
# cross-build produces no VMS-native LINK.EXE graph, see build log
# "OVMX_LINK_NATIVE off ... alpha-linux-gnu is not aarch64/x86_64-musl").
# DECNETD.EXE (rd vms-c1f/vms-f40): the DECnet Phase IV endnode -- staged
# here (not started; no startup procedure runs it) so the shared DCL/SHOW
# acceptance battery DECnet CTERM section hard-gates on this rail the same
# way it does on x86_64/VAX. Alpha is Linux-ABI, so its DECNETD.EXE links
# against libdatalink AF_PACKET backend (the same backend x86_64 uses),
# not the NetBSD bpf(4) one VAX needs. (No apostrophes in this block -- it
# runs inside the assemble docker bash -c single-quote.)
for e in PROVISION.EXE JOB_CONTROL.EXE LOGINOUT.EXE DCL.EXE HELP.EXE \
AUTHORIZE.EXE MAIL.EXE MONITOR.EXE INITIALIZE.EXE INSTALL.EXE \
SYSGEN.EXE PRODUCT.EXE LIBRARIAN.EXE ANALYZE.EXE \
SYSMAN.EXE; do
SYSMAN.EXE DECNETD.EXE; do
[ -f "$BIN/$e" ] && cp "$BIN/$e" "$SYSEXE/" || echo " (no $e)"
done
# IMGACT.EXE (alpha) is the FIRST of the five mandatory first-hop images the
Expand Down Expand Up @@ -294,7 +301,10 @@ docker run --rm --memory=8g --cpus="$(nproc)" \
# IMGACT.EXE + JOB_CONTROL.EXE included: the boot-image staging bridge
# (ovmx_init.c stage_boot_images) requires all five first-hop images on the
# volume, so verify them here rather than discover a miss only at boot.
for name in IMGACT.EXE PROVISION.EXE DCL.EXE JOB_CONTROL.EXE LOGINOUT.EXE SYSUAF.DAT; do
# DECNETD.EXE (rd vms-c1f) is in the same gate: the DCL acceptance
# battery DECnet CTERM section hard-gates on it, so a staging regression
# that drops it off this rail volume must fail HERE too.
for name in IMGACT.EXE PROVISION.EXE DCL.EXE JOB_CONTROL.EXE LOGINOUT.EXE SYSUAF.DAT DECNETD.EXE; do
grep -qi "$name" /work/distrib-list.txt \
|| { echo "FAIL: mastered ODS-2 image missing SYS\$SYSTEM:$name"; exit 1; }
echo " OK: ovmx-distrib-alpha.img (ODS-2) carries SYS\$SYSTEM:$name"
Expand Down
Loading