Initial QNX8 QEMU images for x86_64 and arm64

[jgetas]

Add OS image modules for building QNX8 x86_64 and arm64 images running on QEMU.

Dependency is mainly a QNX SDP 8.0.3 with virtio driver ("block" and "startup") support. See qnx8/README.md.

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
2026/03/31 08:30:14 Downloading https://releases.bazel.build/8.4.2/release/bazel-8.4.2-linux-x86_64...
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 02115ee0-c4d6-4602-88b9-e735d7e0b967
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
WARNING: For repository 'score_tooling', the root module requires module version score_tooling@1.1.0, but got score_tooling@1.1.2 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'score_python_basics', the root module requires module version score_python_basics@0.3.0, but got score_python_basics@0.3.4 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'aspect_rules_lint', the root module requires module version aspect_rules_lint@1.3.1, but got aspect_rules_lint@2.3.0 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'buildifier_prebuilt', the root module requires module version buildifier_prebuilt@7.3.1, but got buildifier_prebuilt@8.5.1 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'score_bazel_platforms', the root module requires module version score_bazel_platforms@0.0.3, but got score_bazel_platforms@0.1.1 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
WARNING: Target pattern parsing failed.
ERROR: Skipping '//:license-check': no such target '//:license-check': target 'license-check' not declared in package '' defined by /home/runner/work/os_images/os_images/BUILD
ERROR: no such target '//:license-check': target 'license-check' not declared in package '' defined by /home/runner/work/os_images/os_images/BUILD
INFO: Elapsed time: 16.791s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

[Copilot]

Pull request overview

This PR adds OS image modules for building QNX8 x86_64 and arm64 images that run on QEMU. The implementation requires QNX SDP 8.0.3 with virtio driver support for block and startup components.

Changes:

• Added QNX8 QEMU board configurations for x86_64 and arm64virt architectures with virtio drivers
• Integrated QNX toolchain dependencies and build configurations
• Created documentation and helper scripts for building and running the images

Reviewed changes

Copilot reviewed 29 out of 29 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
qnx8/boards/qemu-x86_64/target.build	Defines x86_64 QEMU target configuration including drivers, network setup, and startup scripts
qnx8/boards/qemu-x86_64/run-qemu-x86_64.sh	QEMU launch script for x86_64 with KVM acceleration and network/disk configuration
qnx8/boards/qemu-x86_64/qemu-x86_64.build	Build configuration for x86_64 QNX OS image with startup parameters
qnx8/boards/qemu-x86_64/net-start.sh	Network initialization script for x86_64 setting up static IP or DHCP
qnx8/boards/qemu-x86_64/mount-fs.sh	File system mounting script probing for QNX6 partitions
qnx8/boards/qemu-x86_64/misc-services.sh	Service startup script for qconn, sshd, and custom autostart
qnx8/boards/qemu-x86_64/initscript	Main initialization script orchestrating system startup sequence
qnx8/boards/qemu-x86_64/blk-start.sh	Block device driver initialization and RAM disk setup
qnx8/boards/qemu-x86_64/BUILD	Bazel build rules for creating the x86_64 IFS image and run script
qnx8/boards/qemu-arm64virt/target.build	Defines arm64virt QEMU target configuration with ARM-specific drivers
qnx8/boards/qemu-arm64virt/run-qemu-arm64virt.sh	QEMU launch script for arm64 with virt machine type
qnx8/boards/qemu-arm64virt/qemu-arm64virt.build	Build configuration for arm64 QNX OS image
qnx8/boards/qemu-arm64virt/net-start.sh	Network initialization script for arm64virt
qnx8/boards/qemu-arm64virt/mount-fs.sh	File system mounting script for arm64virt
qnx8/boards/qemu-arm64virt/misc-services.sh	Service startup script for arm64virt
qnx8/boards/qemu-arm64virt/initscript	Main initialization script for arm64virt
qnx8/boards/qemu-arm64virt/blk-start.sh	Block device driver initialization for arm64virt
qnx8/boards/qemu-arm64virt/BUILD	Bazel build rules for arm64virt IFS image
qnx8/boards/common/ssh_host_rsa_key.pub	SSH host RSA public key for sshd service
qnx8/boards/common/ssh_host_rsa_key	SSH host RSA private key
qnx8/boards/common/ssh_host_ed25519_key.pub	SSH host ED25519 public key
qnx8/boards/common/ssh_host_ed25519_key	SSH host ED25519 private key
qnx8/boards/common/common.build	Common build configuration shared between architectures including drivers, libraries, and utilities
qnx8/boards/common/BUILD	Bazel exports for common files used across board configurations
qnx8/README.md	Documentation for building and running QNX8 QEMU images
project_config.bzl	Updated project configuration removing rust source code entry
README.md	Root documentation describing OS images module purpose and features
MODULE.bazel	Added QNX toolchain dependency and configuration
.bazelrc	Added QNX toolchain settings and platform configuration

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 15 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[pawelrutkaq]

please use name as in other repos ie arm64-qnx8

[jgetas]

I could do this but this is supposed to be used for x86_64 as well, because it is independent from target architecture - just using the host sdp. I did not want to create 2 configs with duplicate content.

[pawelrutkaq]

if " score_qnx_ifs_toolchain//:ifs-aarch64-qnx-sdp_8.0.0" is host x86 and target qnx8 arch/x86(is it ?) then why not the same here ?

[pawelrutkaq]

its not going to work for others or ? this is dev dep anyway.

[jgetas]

? What do you mean? The sdp.BUILD? I wanted to have this in the rules_imagefs, but Nikola objected. Therefore I had to add it here. The content is IMHO generic for all QNX SDPs. So I don't expect this file will change.

[pawelrutkaq]

I am asking whether each consumer of this repo now needs to have this file ? since imagefs.sdp( is dev_dep here so it not exposed.

[pawelrutkaq]

Looks better, can You please create PR in ref_int to show usage there, before merging so we can see usability and correct if needed?

[pawelrutkaq]

I am asking whether each consumer of this repo now needs to have this file ? since imagefs.sdp( is dev_dep here so it not exposed.

[pawelrutkaq]

if " score_qnx_ifs_toolchain//:ifs-aarch64-qnx-sdp_8.0.0" is host x86 and target qnx8 arch/x86(is it ?) then why not the same here ?

[pawelrutkaq]

Can you please print out at begging netowrk vars& value and info that which can be set ?

[ltekieli]

1. Consistency Issues

1.1 Massive code duplication between arm64virt and x86_64 boards

The following files are identical between qemu-arm64virt/ and qemu-x86_64/:

File	Identical?
misc-services.sh	Yes — byte-for-byte identical
mount-fs.sh	Yes — byte-for-byte identical
net-start.sh	Nearly — differs only in HOSTNAME, io-sock args, and one DHCP config path (/boot/etc/ vs /system/etc/)
blk-start.sh	Nearly — differs only in devb-virtio args (smem=0xa003e00,irq=79 on arm64) and timeout (30 vs 3)
run-qemu-*.sh	Structurally identical — differs in QEMU binary, machine type, KVM opts

This violates DRY and will cause maintenance drift. misc-services.sh and mount-fs.sh are already shared concepts (they live in common/ for other resources) but are duplicated as board-specific files.

Fix: Move misc-services.sh and mount-fs.sh into qnx8/boards/common/. For net-start.sh and blk-start.sh, extract a shared template and use board-specific variable overrides.

1.2 Inconsistent DHCP config path in net-start.sh

• arm64virt: /boot/etc/dhcpcd/dhcpcd.conf and /boot/etc/dhcpcd/dhcpcd-run-hooks
• x86_64: /system/etc/dhcpcd/dhcpcd.conf and /system/etc/dhcpcd/dhcpcd-run-hooks

Neither of these paths (/boot/etc/... or /system/etc/...) appears in the IFS build files or in the common.build DHCP config section (which places the file at /etc/dhcpcd.conf). This means the DHCP code path would fail silently on both architectures. If DHCP isn't intended to work, these paths should be removed or marked as TODO. If it is, the paths must be corrected.

1.3 Inconsistent PCI_HW_MODULE in arm64virt /etc/profile

qnx8/boards/qemu-arm64virt/target.build sets:

export PCI_HW_MODULE=/lib/dll/pci/pci_hw-bcm2711-rpi4.so

This references a Raspberry Pi 4 PCI module — but the arm64virt image targets QEMU's virt machine, not RPi4. The arm64virt initscript doesn't even start PCI server (unlike x86_64 which does). This is a copy-paste error from a hardware board profile.

The module pci_hw-bcm2711-rpi4.so is also not included in common.build or target.build, so the env var points to a non-existent file.

Fix: Remove this line from arm64virt's /etc/profile, or replace it with the correct QEMU virt PCI module if PCI is needed.

1.4 BUILD file formatting inconsistency

qemu-arm64virt/BUILD:

qnx_ifs (               # space before paren
    name = "ifs-qemu-arm64virt",
    build_file = "qemu-arm64virt.build",
    srcs = ["target.build",    # single-line list start
        "initscript",
        "//qnx8/boards/common:common_files"] + glob(...)

qemu-x86_64/BUILD:

qnx_ifs(                # no space before paren
    name = "ifs-qemu-x86_64",
    build_file = "qemu-x86_64.build",
    srcs = [             # proper multi-line list
        "target.build",
        "initscript",
        "//qnx8/boards/common:common_files",
    ] + glob(...)

The x86_64 version is correctly formatted (per Buildifier); arm64virt is not. Run buildifier on all BUILD files before merging.

1.5 initscript differences not justified

• arm64virt has random (bare command) in its init sequence.
• x86_64 has pci-server, rtc, and random via ksh -c "random -l /lib/dll/devr-virtio.so".
• arm64virt lacks rtc entirely.

Some of this is legitimate (PCI is configured differently), but the divergence in random invocation is suspicious. The # no idea why, but need to start random in a ksh shell... comment in x86_64's initscript suggests this was a workaround — it should be investigated, not shipped.

1.6 HOSTNAME inconsistency

• arm64virt: HOSTNAME=qemu-arm64virt (hyphenated, consistent with board directory name)
• x86_64: HOSTNAME=x86_64qemu (not hyphenated, reversed order, doesn't match directory name qemu-x86_64)

Fix: Use HOSTNAME=qemu-x86_64 for consistency.

---

2. Architectural Review: Image-as-Target vs Binary Artifact

2.1 Current architecture: binary artifact

The PR produces the IFS image as a qnx_ifs rule output — a binary file. The run-qemu.sh scripts are standalone shell scripts that:

1. Create a QCOW2 disk on-the-fly if one doesn't exist.
2. Launch QEMU with hardcoded network settings.
3. Provide no programmatic interface for configuration.

The output is a binary blob + a shell script. Consumers must either:

• Use the shell script as-is (inflexible).
• Manually extract the IFS binary and write their own QEMU invocation.
• Copy/modify the shell script for their use case.

2.2 Required architecture: image-as-Bazel-target

The IFS image should be a Bazel target that other Bazel modules can depend on via standard bazel_dep + label references. This is partially achieved (the qnx_ifs target has visibility = ["//visibility:public"]), but the overall design treats the image as a standalone deliverable rather than a composable dependency.

What's missing for true target-based consumption:

1. No provider for downstream consumption. The qnx_ifs rule returns DefaultInfo with the binary file, but there's no structured provider that carries metadata (architecture, OS version, supported features, network config defaults). Downstream rules like ITF's py_itf_test or a future qemu_target rule need this metadata to configure QEMU correctly.

2. The run script is not a Bazel-native target. The genrule that copies the run script is a workaround. A proper qemu_run rule should accept an IFS target + configuration and produce a runnable target that Bazel manages end-to-end.

3. The QCOW2 disk creation happens at runtime, outside Bazel. This means the disk image is not hermetic, not cached, and not reproducible. It should be created by a Bazel rule (diskimage from rules_imagefs exists for this purpose) and passed as a dependency.

Recommended structure:

# Produces the IFS binary as a Bazel target
qnx_ifs(
    name = "ifs-qemu-arm64virt",
    ...
)

# Produces the disk image as a Bazel target (currently done at runtime)
diskimage(
    name = "disk-qemu-arm64virt",
    ...
)

# Composable QEMU launch target
qemu_target(
    name = "qemu-arm64virt",
    ifs = ":ifs-qemu-arm64virt",
    disk = ":disk-qemu-arm64virt",
    arch = "aarch64",
    memory = "1G",
    cpus = 2,
    network = "user",  # or "bridge", "tap"
    ssh_port = 2210,
)

2.3 No external module consumption story is tested

The README documents bazel build @os_images//qnx8/boards/qemu-... --config=qnx8_0, but:

• The --config=qnx8_0 flag is defined in this repo's .bazelrc — it won't exist in the consumer's repo.
• The consumer would need to replicate the QNX toolchain setup, platform definitions, and credential helper in their own .bazelrc.
• No example external module exists to validate this works.

Fix: Document what .bazelrc entries consumers need. Better: provide a macro (e.g., register_qnx_toolchains()) that consumers call in their MODULE.bazel.

---

3. Feature-Based Image Composition API (Future Architecture)

3.1 The problem with the current static approach

The current PR produces two monolithic images with hardcoded features:

• SSH always enabled
• Network always enabled with static IP
• qconn always included
• All toybox utilities included
• Full PCI stack included (even on arm64 where PCI server isn't started)
• Security policy tools included
• DLT/DoIP port forwarding in run scripts

This "kitchen sink" approach works for initial bring-up but doesn't scale. Different test tiers need different image profiles:

• UT images: Minimal — no network, no SSH (use virtio9p), smallest possible IFS.
• CIT/FIT images: SSH + network, maybe DLT support, no debug tools.
• PIT images: Full feature set including diagnostics.
• Security-hardened images: No empty passwords, no qconn, minimal attack surface.

3.2 Recommended feature-based API design

The os_images module should evolve toward a macro-based API where users declare which features they want:

load("@os_images//qnx8:image.bzl", "qnx_image")

# Minimal image for unit testing (fast boot, small size)
qnx_image(
    name = "qnx-ut-image",
    board = "qemu-arm64virt",
    features = [
        "base",        # kernel + minimal libs
        "shell",       # ksh + basic utilities
    ],
)

# Full image for integration testing
qnx_image(
    name = "qnx-cit-image",
    board = "qemu-arm64virt",
    features = [
        "base",
        "shell",
        "ssh",         # sshd + keys (generated at boot)
        "network",     # io-sock + ifconfig + static IP
        "qnx6fs",      # block driver + mount support
        "toybox",      # common CLI utilities
    ],
    network_config = {
        "ip": "192.168.120.20/24",
        "hostname": "qnx-test",
    },
)

# Image with custom content deployed via rules_pkg
qnx_image(
    name = "qnx-pit-image",
    board = "qemu-arm64virt",
    features = ["base", "shell", "ssh", "network", "qnx6fs", "toybox", "dlt", "pci"],
    content = ":my-test-content-pkg",  # rules_pkg tar target
)

3.3 Implementation roadmap for feature-based API

Phase 1 (this PR — restructure for future):

• Split common.build into feature-specific .build fragments:
  • features/base.build — kernel libs, dynamic linker
  • features/ssh.build — sshd, keys, PAM config
  • features/network.build — io-sock, ifconfig, network utilities
  • features/shell.build — ksh, toybox
  • features/pci.build — PCI server and modules
  • features/debug.build — qconn, pdebug, dumper
  • features/security.build — secpol utilities
• Keep the current qnx_ifs targets as "default" profiles that include all features.
• Make each feature fragment a separate filegroup target.

Phase 2 (follow-up PR — composable API):

• Create a qnx_image macro that:
  • Accepts a features list.
  • Assembles the corresponding .build fragments via [+include] directives.
  • Generates the board-specific initscript with conditional service startup.
  • Returns a provider with image metadata.

Phase 3 (custom content via rules_pkg):

• Accept a content attribute that takes a rules_pkg pkg_tar target.
• The macro generates a qnx6fs or diskimage target containing the content.
• The content is mounted at /opt/score at boot, same as today's approach.

3.4 rules_pkg integration for custom content deployment

Currently, test content is deployed via manual qnx6fs partition creation (either online via shell commands or offline via mkqnx6fsimg). This should be declarative:

load("@rules_pkg//pkg:tar.bzl", "pkg_tar")
load("@os_images//qnx8:content.bzl", "qnx_content_partition")

# Package test binaries and scripts
pkg_tar(
    name = "my-test-content",
    srcs = [
        "//my_module:test_binary",
        "//my_module:test_config",
    ],
    package_dir = "opt/score/tests",
)

# Create a qnx6fs partition image from the content
qnx_content_partition(
    name = "my-test-partition",
    content = ":my-test-content",
    size = "128M",
    autostart = "opt/score/tests/run_all.sh",  # optional autostart script
)

# Compose: OS image + content partition → runnable QEMU target
qemu_target(
    name = "my-test-env",
    ifs = "@os_images//qnx8/boards/qemu-arm64virt:ifs-qemu-arm64virt",
    partition = ":my-test-partition",
    network = "user",
    ssh_port = 2210,
)

This approach:

• Keeps OS images generic and reusable (never rebuilt for each test case).
• Makes test content hermetic and tracked by Bazel.
• Enables ITF integration: py_itf_test can take qemu_target as a dependency.
• Uses standard rules_pkg for content packaging — no QNX-specific tooling needed for creating the content (only for creating the partition image).

---

4. ITF Compatibility Assessment

4.1 Current ITF compatibility

ITF's QEMU plugin (QemuTarget) requires:

• An IFS image bootable by QEMU.
• SSH server running on the target with known credentials.
• Network connectivity (bridge or port-forwarding).

The images produced by this PR satisfy all three requirements. However:

4.2 Integration gaps

1. Port forwarding config mismatch: The run scripts hardcode SSH on port 2210, but ITF's QEMU plugin configures port forwarding via JSON config (qemu_config.json). There's no bridging between these two approaches — a consumer would need to ignore the run scripts entirely and use ITF's own QEMU launch logic.

2. IFS target metadata: ITF's QEMU plugin needs to know the architecture, memory requirements, and QEMU machine type. This information exists only in the run scripts, not as Bazel-queryable metadata on the IFS target. A provider on the qnx_ifs target would solve this.

3. No py_itf_test example: The README should show how to use the produced IFS image with ITF's py_itf_test macro. This is the primary intended consumption path for CIT/FIT/PIT.

---

5. CI/Build Issues

5.1 License check target missing

The automated license check fails because //:license-check target doesn't exist in the BUILD file. The score_tooling module presumably provides this but it's not wired up.

5.2 Stale dependency versions

The MODULE.bazel has multiple version mismatches flagged by Bazel:

• score_tooling: requires 1.1.0, resolved 1.1.2
• score_python_basics: requires 0.3.0, resolved 0.3.4
• aspect_rules_lint: requires 1.3.1, resolved 2.3.0
• buildifier_prebuilt: requires 7.3.1, resolved 8.5.1
• score_bazel_platforms: requires 0.0.3, resolved 0.1.1

These should be updated to match the resolved versions.

5.3 imagefs.sdp marked as dev_dependency = True

imagefs = use_extension("...", "imagefs", dev_dependency = True)

This means external consumers of this module cannot build the images because the SDP toolchain is excluded from the dependency graph in non-dev contexts. This contradicts the stated goal of supporting bazel build @os_images//... from external modules.

Fix: Remove dev_dependency = True or document that external consumers must provide their own SDP toolchain.

5.4 Hardcoded aarch64 toolchain only

.bazelrc defines only --config=qnx8_0 with:

common:qnx8_0 --platforms=@score_bazel_platforms//:aarch64-qnx-sdp_8.0.0-posix
build:qnx8_0 --extra_toolchains=@score_qnx_ifs_toolchain//:ifs-aarch64-qnx-sdp_8.0.0

There is no --config for building x86_64 images. The imagefs.toolchain call in MODULE.bazel also only registers the aarch64 toolchain. Building //qnx8/boards/qemu-x86_64:all with --config=qnx8_0 would either fail or use the wrong architecture toolchain.

Fix: Add a qnx8_0_x86_64 config and register the x86_64 toolchain. Or, better: use Bazel platform-based toolchain resolution so that the correct toolchain is selected automatically based on the target platform.

---

6. Minor Issues

#	File	Issue
1	qnx8/boards/qemu-arm64virt/BUILD	Trailing space after qnx_ifs (before paren)
2	MODULE.bazel	Inconsistent closing paren indentation on imagefs.toolchain ( ) instead of ))
3	README.md	Trailing space: # OS images
4	qnx8/README.md	Multiple consecutive blank lines (line 236, etc.)
5	run-qemu-arm64virt.sh	Comment says "Images generated by mkqnximage" — but images are generated by Bazel/mkifs, not mkqnximage
6	run-qemu-x86_64.sh	Same "mkqnximage" comment
7	common.build	[type=link] /tmp_discovery=/run/lola_discovery — lola-specific symlink in "generic" common build
8	target.build (arm64)	export HOME=/ in profile — should be export HOME=/root to match the init script's HOME=/root
9	target.build (x86_64)	Same HOME=/ inconsistency
10	blk-start.sh (arm64)	Timeout of 30s for waitfor /dev/hd0 — will cause very slow feedback on failure
11	common.build	perms=455 for /usr/bin/passwd — likely should be perms=4555 (setuid) like login and su

---

7. Summary of Requested Changes

Must fix before merge:

1. Fix the PCI_HW_MODULE copy-paste error in arm64virt profile (BCM2711/RPi4 reference).
2. Fix the DHCP config path inconsistency between arm64 and x86_64.
3. Fix the dev_dependency = True issue on the imagefs extension — external consumers can't build.
4. Add x86_64 toolchain registration and build config.
5. Fix the CI license check failure.
6. Run buildifier on all BUILD files.
7. Fix the HOSTNAME inconsistency (x86_64qemu → qemu-x86_64).

Should fix before merge:

8. Deduplicate misc-services.sh and mount-fs.sh (move to common/).
9. Fix the HOME=/ vs HOME=/root inconsistency in profiles.
10. Remove the lola-specific /tmp_discovery symlink from the generic common.build or make it conditional.
11. Update stale dependency versions in MODULE.bazel.

Should address via follow-up (architecture):

12. Restructure common.build into feature-specific fragments to enable future feature-based composition.
13. Add a Bazel provider to the qnx_ifs target carrying image metadata (arch, machine type, default ports).
14. Create a qemu_target macro or rule that composes IFS + disk + network config into a runnable, dependable target.
15. Document ITF integration with example py_itf_test usage.
16. Design the rules_pkg-based content deployment pipeline (pkg_tar → qnx_content_partition → qemu_target).