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.
3 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-ramdisk-root-sizing | 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. |
|
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.