SchOS/docs/moving-to-linux.md
Nexoniarz 651899220c boot: the BIOS loader is gone
1449 lines of boot/bios/, tools/sign.pl and tools/padstage2.pl, plus the
build rules, the disk image and the ISO entry that existed to carry them.

Everything since roughly 2012 boots UEFI, and CSM -- the firmware-side
BIOS emulation that lets a legacy loader run on such a machine at all --
has been going away since Intel dropped support for it in 2020. So this
is not a path being retired early; it is one whose remaining hardware is
already the exception.

The cost was never the code, it was the tax on everything near it. Stage
2 had a 65-sector ceiling it overflowed silently -- 25440 bytes against
24576 -- and because the kernel is written at sector 1 + STAGE2_SECTORS,
an overflowing loader was overwritten by the very kernel it was loading.
The resolution list could not be shared with UEFI either: VBE mode
setting is INT 10h, so matching it needed unreal mode, which is the
riskiest code in the tree for a feature that already worked elsewhere.

What replaces schos.img is the staged ESP, handed to QEMU as a virtual
FAT volume. That is a development arrangement and not an installable
disk; a real GPT image with a real FAT partition is the installer's job,
and until it exists nothing here writes a disk a machine boots unaided.
Secure Boot is untouched too -- the loader is unsigned.

The ISO keeps one El Torito entry, the FAT image holding loader and
kernel. It never booted from a USB stick via BIOS anyway: the firmware
presents the stick as a hard disk while stage2main.c read the kernel back
over ATAPI.

The 32-bit multiboot entry in entry.S now has no caller and is left in
place. Deleting kernel entry code is its own change with its own way of
failing silently, and it should not ride along with this one.

Ported with it: run.ps1, the six screenshot tools, and schcom_test.sh,
each with its own OVMF varstore copy so no run inherits another's UEFI
variables.

Two things this shook out. OVMF now belongs in `all`: nothing boots
without firmware, `make clean` wipes build/ including the copy fetched
from the host, and a clean followed by a build left every run script
throwing. And it cannot be listed as a prerequisite at the top of the
file -- make expands prerequisites when it reads the line, and
$(OVMF_CODE) is defined further down, so naming it there appends nothing
and says nothing.

Verified from a clean tree: 110 [ok] and no failures on the full suite,
the ISO boots with no hard disk attached, schfs-check passes, schcom's
end-to-end pixel test passes, and fbshot captures a real 1280x800 frame.
2026-08-11 10:20:28 +02:00

131 lines
5.1 KiB
Markdown

<!-- SPDX-License-Identifier: Apache-2.0 -->
# Moving the project to a Linux machine
Written for the move to `/home/nexoniarz/Documents/SchOS` on Fedora 44. Nothing
here is Fedora-specific except the package names.
## 1. Copy the repo
Copy the whole directory, `.git` included. Everything that matters is committed
— 17 commits, no remote — and that includes the project memory, which lives in
`.claude/memory/` precisely so it survives this.
```sh
# whatever transport suits: a USB stick, rsync, scp
rsync -a /path/to/SchOS/ /home/nexoniarz/Documents/SchOS/
cd /home/nexoniarz/Documents/SchOS
git log --oneline | head -3 # should show the same commits
git status # should be clean
```
### What is not in the repo
`build/`, `sysroot/` and `dist/` are all gitignored, so `rsync -a` of the
working tree carries them but a `git clone` would not. Two are worth thinking
about:
- **`dist/`** holds the upstream tarballs — musl, toybox, mksh, the DOOM WADs,
`usb.ids`. 61 MB of other people's release artefacts. Copy it to save the
download, or let the build fetch them again; `make ports` calls `curl` and
verifies each against a known SHA-256, so a re-download is safe either way.
Without a network connection, copy it.
- **`sysroot/`** is assembled by the build, so it does not need copying — and
on this machine it should not be. Its `bin/` holds musl, toybox and mksh,
staged once because Windows cannot build them. Linux can, so let `make ports`
produce them rather than carrying stale binaries across: the staged copies
predate the rename, and `sysroot/bin/sh` still contains `__schunix_tp`.
- **`build/`** is pure output. Delete it and forget it.
## 2. Restore the memory
Claude Code keeps per-project memory under a key derived from the project's
absolute path, so it differs per machine:
| | |
|---|---|
| `D:\DEV\SchOS` | `D--DEV-SchOS` |
| `/home/nexoniarz/Documents/SchOS` | `-home-nexoniarz-Documents-SchOS` |
One command puts it where this machine looks:
```sh
tools/posix/memory-sync.sh status # shows both sides, changes nothing
tools/posix/memory-sync.sh import # repo -> ~/.claude/projects/<key>/memory/
```
That writes to
`/home/nexoniarz/.claude/projects/-home-nexoniarz-Documents-SchOS/memory/`.
After a session that learned something, `export` and commit, so the knowledge
travels back:
```sh
tools/posix/memory-sync.sh export && git add -A && git commit -m "memory: ..."
```
## 3. Install the toolchain
```sh
tools/posix/setup-fedora.sh --check # report what is missing
tools/posix/setup-fedora.sh # install it
```
That covers clang, lld, llvm, make, gcc, perl, python3, qemu-system-x86,
edk2-ovmf, xorriso and mtools. See [building.md](building.md) for what each is
for and for the other supported hosts.
**PowerShell is the one thing dnf cannot supply.** `tools/windows/bootcheck.ps1`
is the boot test suite, and `pwsh` runs it on Linux perfectly well — there is
simply no Fedora package. The script prints the two ways to get it. Nothing
else needs it: `make`, `make schfs-check` and `make qemu` all work without.
## 4. Build and check
```sh
make # kernel + root filesystem
make schfs-check # B-tree, object and image suites -- all host-native
make qemu # boot it
```
Two things will behave differently here, both improvements:
- **`make ports` works.** musl, toybox and mksh build from source. On Windows
the build skips them and uses whatever is staged.
- **The SchFS round-trip test runs.** It needs symlinks and hard links, which
Git Bash cannot create, so on Windows it skips with a message. This is the
first machine that can actually exercise that path — worth running early,
since it is the one part of SchFS never yet tested.
## 5. KVM
A Ryzen 7000 has SVM, so QEMU can run at native speed instead of emulating:
```sh
ls -l /dev/kvm # should exist
sudo usermod -aG kvm $(id -un) # if it exists but is not readable
```
Then add `-enable-kvm` to a QEMU command line. It is deliberately **not** the
default in the Makefile: the test suite's timings were established under TCG,
and changing the execution engine underneath them is a variable worth
introducing on purpose rather than by accident.
## 6. UEFI
`make qemu-uefi` boots the UEFI path under OVMF. The Makefile searches the
usual locations for the firmware and Fedora's `edk2-ovmf`
(`/usr/share/edk2/ovmf/OVMF_CODE.fd`) is among them.
Note the open bug before spending time on it: under OVMF the kernel reports
`e820: only 8 MB usable`, because `e820_init` takes the usable run *containing
the kernel* and OVMF puts an ACPI NVS region at 0x800000, genuinely fragmenting
it. The loader's map is correct; the kernel's one-contiguous-run assumption is
BIOS-shaped. The fix is to free each usable region rather than one range, which
touches `kalloc`.
## The hardware, for reference
Fedora 44, Ryzen 5 7000-series, RTX 4050, 16 GB DDR5. Nothing in the build cares
about the GPU — QEMU runs headless for tests and uses its own emulated display
otherwise. The Nvidia driver matters only if you want a QEMU window, and the
`nouveau`/proprietary choice makes no difference to SchOS either way.