nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

Rewrite run.ps1; it was five kinds of stale

Browse source 
run.ps1 is a .ps1 that does not live under tools/, so every sweep that
fixed the other launchers went straight past it:

  - hdb defaulted to build/fs.img, which nothing builds since SchFS
    became the root, so it pointed at a file that does not exist. QEMU
    came up with no usable disk on device 1 and the kernel panicked with
    SCHFS_ROOT -- "no SchFS volume on the root device". That is exactly
    the failure this script exists to prevent.
  - a -SchFS switch built around the old arrangement, where SchFS was a
    secondary volume and needed `make ramroot` to free device 1. There
    is no such arrangement now; every boot is a SchFS boot.
  - `cd /d/DEV/SchOS` hardcoded into the build invocation. It survived
    the Schunix -> SchOS rename by luck and would break on any clone.
    Derived from $PSScriptRoot now.
  - a hardcoded scoop QEMU path, and build\ backslash literals.
  - only -vga std, where the Makefile also attaches virtio-gpu-pci.

The magic check is SchFS-only now and prints the bytes it actually read
when it fails.

SchFS itself is fine: it mounts on 1, 2 and 4 CPUs, and all seven
bootcheck suites pass.
This commit is contained in:
Nexoniarz 2026-08-09 14:49:47 +02:00
commit 66340e720e
2 changed files with 106 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

33
.claude/memory/schos-cross-platform-build.md
View file

@ -56,3 +56,36 @@ not a theoretical one.
written from documented behaviour and have **never been executed** — this
machine has no WSL and no second host. Windows is the only host where the build
and `tools/bootcheck.ps1` have actually been run green.
## run.ps1 is at the repo root, so tool sweeps miss it
It is a `.ps1` but it does **not** live under `tools/`, and it went stale in
five ways at once while every tool beside it was fixed: hdb defaulting to
`build/fs.img` (which nothing builds any more, so the file simply does not
exist), a `-SchFS` switch built around the old arrangement where SchFS was a
secondary volume, a hardcoded QEMU path, `build\` backslash literals, and
`cd /d/DEV/SchOS` hardcoded into the build invocation -- which survived the
Schunix -> SchOS rename by luck and would break on any clone. Rewritten
2026-08-09. **When sweeping the tools, check the repo root too.**
## The stale-image trap bit again, and it looks exactly like a filesystem bug
A leftover headless QEMU holds `schos.img` and `build/schfs.img` open. On
Windows that makes `rm` fail with *Device or resource busy*, so `make` stops
**after** the kernel has relinked -- leaving a stale `schos.img` that boots the
previous kernel. The symptom this time was a PSOGM reading
`schfs root: no SchFS volume on the root device`, which reads as SchFS being
broken and is not: SchFS mounts cleanly on 1, 2 and 4 CPUs.
`kill %1` from Git Bash does not reliably kill a Windows QEMU. Use:
```sh
pwsh -NoProfile -Command "Get-Process qemu-system-x86_64 -ErrorAction SilentlyContinue | Stop-Process -Force"
```
A tell: `ls -l schos.img` showing anything other than **5,120,000 bytes**
(`dd count=10000`) means the image was not rewritten and is stale.
**Rule: before believing a boot failure, confirm no QEMU is running and that
schos.img was written by the build you think it was.**