tools/posix/setup-fedora.sh installs the toolchain and reports what it cannot: PowerShell has no Fedora package, and bootcheck is the test suite, so the script says how to get pwsh rather than failing quietly. It also checks /dev/kvm, since a Ryzen box can run the tests at native speed. docs/moving-to-linux.md is the actual procedure: copy the repo, restore the memory, install, build. The memory travels inside the repo and `memory-sync.sh import` puts it under the key this machine derives from its own path -- /home/nexoniarz/Documents/SchOS becomes -home-nexoniarz-Documents-SchOS, where D:\DEV\SchOS was D--DEV-SchOS. OVMF discovery no longer assumes QEMU's Windows layout. Fedora ships edk2-ovmf to /usr/share/edk2/ovmf/, Debian and Arch differ again, so the Makefile searches a list and names the packages when it finds nothing. Tested through the shell rather than $(wildcard): on Windows make is a native binary using Win32 file calls, while `command -v` returns an MSYS path like /c/Users/..., which $(wildcard) cannot see -- it returned nothing on a machine that had the firmware. Two things only that machine can test: `make ports` builds musl, toybox and mksh from source, which Windows cannot do at all; and the SchFS round-trip needs symlinks and hard links, so it has never actually run.
120 lines
4.6 KiB
Markdown
120 lines
4.6 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
|
|
```
|
|
|
|
`build/` and `sysroot/` are ignored and do not need copying — `make` rebuilds
|
|
them. **One exception**: `sysroot/bin/` holds musl, toybox and mksh, which
|
|
cannot be built on Windows and so were staged there once. On Linux they *can*
|
|
be built, so let the build produce them (`make ports`) rather than carrying
|
|
stale binaries across. The staged copies predate the SchOS rename anyway —
|
|
`sysroot/bin/sh` still contains the symbol `__schunix_tp`.
|
|
|
|
## 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 -> schos.img
|
|
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.
|