3182da3965
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:
- D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
invisible until moved across by hand.
- Development happens from Windows and from Linux, and each looks in a
different place for the same checkout.
Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.
The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
55 lines
3 KiB
Markdown
55 lines
3 KiB
Markdown
---
|
|
name: schunix-ramdisk-root-sizing
|
|
description: "Why `make iso` was failing with \"disk full\" — DOOM WADs in the ramdisk, not FSSIZE — and the three Makefile knobs that actually control that image."
|
|
metadata:
|
|
node_type: memory
|
|
type: project
|
|
originSessionId: 9d8a2aef-bcf0-47a0-96c6-f706efab4a95
|
|
modified: 2026-08-08T12:04:27.952Z
|
|
---
|
|
|
|
Fixed 2026-08-08. `make iso` died with `mkfs: disk full -- used 6000 of 6000
|
|
blocks` and the advice "Increase FSSIZE in param.h". **`FSSIZE` was 150000 and
|
|
entirely innocent.** The ramdisk root's size is `RAMDISK_BLOCKS` in the Makefile.
|
|
The error message has been rewritten to name the right knob per image and print
|
|
the metadata breakdown; don't trust the old advice if it resurfaces anywhere.
|
|
|
|
**The actual cause: `make doom` stages 33 MB of WADs into `sysroot/`**
|
|
(`freedoom1.wad` 28.8 MB, `doom1.wad` 4.2 MB) and the ramdisk was trying to
|
|
swallow them into 6 MB. Real userland is only ~1.9 MB — the 244 `/bin` entries
|
|
are *hardlinks* to one 822 KB toybox, which is why `du` says 35 MB while the
|
|
file sizes sum to 229 MB.
|
|
|
|
**This is a licensing rule, not just a size one, and that is the reason it is
|
|
enforced in the build rather than by remembering to run `make doom-uninstall`.**
|
|
The ramdisk is linked *into the kernel binary*; `doom1.wad` is
|
|
non-redistributable shareware, so a kernel containing it could not be
|
|
distributed. See [[schunix-doom-acceptance-test]] and [[schunix-licensing]].
|
|
|
|
Three Makefile knobs, none of them FSSIZE:
|
|
- `RAMDISK_BLOCKS` (6000) — image size, BSIZE is 1024.
|
|
- `RAMDISK_NINODES` (2000) — **the inode table is preallocated.** mkfs's default
|
|
12000 inodes cost 1501 of 6000 blocks, a quarter of the image, for ~260 files.
|
|
Metadata went 1596 → 345 blocks.
|
|
- `RAMDISK_EXCLUDE` (`usr/share/doom bin/doom`) — `mkfs --exclude <relpath>`,
|
|
repeatable, drops a whole subtree and prints what it skipped.
|
|
|
|
`mkfs` gained `--ninodes` and `--exclude`. Its option parser used to handle
|
|
exactly one flag then `break`, silently ignoring a second — now it compacts argv
|
|
properly, but both modes still identify themselves *positionally* (argv[2] is
|
|
`--sysroot` or the first file), so keep that contract if adding options.
|
|
|
|
**Verified:** ramroot boots with no disk attached at all, and the ISO boots from
|
|
optical media only (`ide: no drive on the primary channel`) to a full shell with
|
|
243 commands — 243 not 244 because `doom` is correctly excluded.
|
|
|
|
**`make iso` needs `mkisofs`, not xorriso, on this host.** There is no xorriso
|
|
package in scoop; cdrtools provides `mkisofs.exe` and was already installed.
|
|
`tools/mkiso.sh` now takes either — the El Torito flags are argument-compatible.
|
|
This also finally verified `-boot-load-size 49` (see
|
|
[[schunix-boot-splash-logo]]), which was untestable while xorriso was missing.
|
|
|
|
**Trap:** `make iso` builds the ramroot variant and does `rm -rf build/kernel`
|
|
first, so a failed run leaves objects compiled with `-DRAMDISK_ROOT` and the next
|
|
plain `make` dies on `_binary_ramdisk_size`. Recover with
|
|
`rm -rf build/kernel build/lib build/cmd`.
|