Prepare for the move to Fedora

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.

docs/building.md

@@ -104,6 +104,16 @@ outstanding:
   `Join-Path $root 'build\x'` produces a *filename containing a backslash* on a
   Unix host.
 
+## Fedora, in one command
+
+```sh
+tools/posix/setup-fedora.sh --check   # what is missing
+tools/posix/setup-fedora.sh           # install it
+```
+
+Moving an existing checkout to a Linux machine: see
+[moving-to-linux.md](moving-to-linux.md).
+
 ## Working on two machines
 
 Claude Code's project memory is kept in the repo and moved with:

docs/moving-to-linux.md

@@ -0,0 +1,120 @@
+<!-- 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.