Last entry, a Node.js Discord bot ran on a kernel that was never Linux. Since then the package manager grew teeth: apk add went from extracting a hand-built fixture to installing and running real, unmodified upstream Alpine packages. Along the way we dogfooded two completely different corners of the Linux ABI, hardened the shell's command surface, taught the NTFS writer to fragment files — and watched a single record-level filesystem bug step out of the shadows as the one thing standing between us and a Windows-validated volume.

apk Now Installs Real Software

The chain that started with apk add reaching exit status 0 now ends with binaries that actually execute under chroot(/alpine). We worked through a stack of real packages, each one chosen to lean on a different part of the kernel:

Package	What it exercises
tree, jq	Dynamic linking; jq loads its oniguruma .so by SONAME symlink
pax-utils (scanelf)	Parses ELF the same way our own loader does — dogfooding the dynamic-loader path
lua5.4	A second interpreter, plus a two-level subdirectory SONAME-symlink chain
findutils (find, xargs)	Hammers getdents64/openat/fstatat — the filesystem-syscall surface
file (libmagic)	Loads, runs --version; its 10 MB magic database found us a new bug (below)

Two ABI Surfaces, Both Green

The interesting part is that these split cleanly into two stress tests. The dynamic-loader path — musl's ld.so opening a library by its SONAME symlink — carried jq, scanelf, and lua5.4. The filesystem-syscall path — directory walks via getdents64 and stat-at calls — carried find and xargs, which happily listed real jail directories and pipe-forked through xargs. Two surfaces, both running real software, neither one a fixture we wrote.

open() Learns to Follow Symlinks — Even Fake Ones

The loader story only works because open()/openat() now follow JefeOS's JSYML symlink shims correctly. The subtle bug: when a followed symlink resolved to a synthetic node — a /proc-style file the kernel materializes on demand — the dispatch fell through to the device-node arm and handed back /dev/urandom. So a symlink like /etc/mtab → /proc/mounts read as random bytes. Moving the follow to the top of the open path so a followed target re-enters every kind-specific arm fixed it; the chroot jailer that resolves the target string is untouched, so containment held.

The NTFS Writer Grows Up: Fragmented Writes

The writer had a quiet limitation: allocate_clusters only ever returned a single contiguous run, so a large file on a fragmented volume failed even with plenty of total free space. We taught it to greedily claim multiple runs and build a proper NTFS data-run list — first run absolute, each subsequent run a signed delta from the previous run's start LCN, terminated and byte-verified against the on-disk spec. A 2 MB write came back byte-identical across 6 runs; an 11 MB write across 9. The read path already traversed multi-run $DATA for Windows-written files, so the encoder just had to match its conventions.

One Bug to Gate Them All

Here's the find of the week. The fragmented $DATA is provably correct — yet Windows chkdsk /f still rejects the file. Why? Because chkdsk deletes the whole MFT FILE record at the $STANDARD_INFORMATION/$FILE_NAME level before it ever reaches the data runs. The same record-level writer defect blocks the directory-index B+tree grow (which we drove through four investigation passes, eliminating LCN collisions, separator layout, index-block fixups, and bitmap accounting one by one) and it's the same gremlin behind the data volume's root directory re-corrupting on every boot. Three symptoms, one root cause. Fixing that single record-writer bug unblocks fragmented large files, the directory grow that closes our oldest filesystem tickets, and the root corruption — all at once. That's the next mission.

A Privilege Gate for the Sharp Edges

On the security side, we added a session-elevation gate so destructive shell commands (reboot, halt, and the deliberate-crash test commands) now require an elevated session rather than running from any remote shell. A security review verified the gate is bypass-resistant and fails closed — even an explicit privilege-bump attempt over SSH stays refused, because the gate keys on the session's remote scope rather than a task flag. Five PRs merged this session, zero reverts, zero regressions.

What's Next

• The record-level MFT writer bug — the common gate. Dump a freshly written FILE record byte-for-byte against a Windows-written one and find the dimension our self-check doesn't cover (prime suspect: the on-disk update-sequence fixup).
• The directory-index grow — fully built and verified against our own reader, waiting behind the same record-writer gate before its feature flag flips on.
• A large-file install path — file's magic database surfaced an unimplemented call in apk's atomic large-file commit, upstream of the NTFS write entirely. Trace it and the database extracts.