ELKS targets 128k of RAM, and its build needs a host cross toolchain first

A 16-bit Linux for CPUs that predate protected mode

ELKS is an early fork of the Linux OS for systems based on the Intel IA16 architecture. The README names the processors: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 and compatibles. The same target list covers very different machines, from an IBM PC XT or AT and its clones through to SBCs, SoCs, FPGAs, and modern 80386 or later x86 desktops.

The memory numbers are the project's headline constraint, and they are stated precisely enough to plan against.

* Stock images require 512k RAM
* ELKS requires 256k RAM to run, 512k to be really useful
* No hardware MMU required
* ROM-based systems can run in 128k RAM

No MMU is the architectural point. There is no virtual memory, no process isolation in the way a modern kernel provides it, and that is what allows a kernel of this size to boot on a processor from 1981.

The feature list in the README covers networking, graphics, and installation to HDD using both MINIX and MSDOS FAT filesystems. That FAT support is what makes the system usable on real period hardware, where the disk is already formatted by the machine's original operating system. Screenshots in the repository show netstat and a process list, a graphical environment on multiple consoles, and Doom running, which is a reasonable indication of how much fits.

The last push was on 2026-10-05. Releases are frequent in this project's terms: v0.9.2 on 2026-09-06, v0.9.1 on 2026-05-06, v0.9.0 on 2026-03-21.

The build refuses to start without a cross toolchain

The Makefile's first act is a guard, and it explains the whole build order in one line.

ifndef TOPDIR
$(error TOPDIR is not defined; run '. ./env.sh' then './build.sh' to build toolchain)
endif

So the sequence is: run build.sh to build the cross toolchain, source env.sh so TOPDIR is set, then use the ordinary make targets. Trying to run make first produces an error telling you exactly that.

Configuration is kconfig, the same system used by the Linux kernel itself. The all target depends on .config and include/autoconf.h, and the available targets include config, defconfig, menuconfig, image, images, kernel, bootblocks, elkscmd, kimage, libc and clean. The clean target prints a reminder if no .config exists, telling you to run make config or make menuconfig.

Three toolchain targets are visible in the Makefile, and they correspond to the three compilers the README mentions. owc builds the OpenWatcom libc and commands with watcom.mk in four models, c, s, m and l. c86 builds the native libc and commands with c86.mk. The default path uses the cross toolchain. There is also a kclean target for the kernel alone, and owclean and c86clean for the two alternative paths.

The all target also builds elksemu, but only when uname is Linux.

ifeq ($(shell uname), Linux)
	$(MAKE) -C elksemu PREFIX='$(TOPDIR)/cross' elksemu
endif

Full instructions live in BUILD.md, and the repository ships several run and emulator helper scripts: qemu.sh, bochs.sh, dosbox.sh, emu86.sh, emuswan.sh, slattach.sh, copyc86.sh, buildc86.sh, buildext.sh and buildimages.sh.

Checked in configs beat menuconfig defaults for a first build

The repository carries a set of configuration files at the top level, and for anyone starting out they are the fastest route to a working image: 8018x.config for the NEC V25, ibmpc-1440.config and ibmpc-1440-nc.config for 1.44MB floppy variants, ibmpc-pmode.config for protected mode, pc98-1200.config, pc98-1232.config, pc98-1232-nc.config and pc98-1440.config for PC-98 machines, necv25.config, plus emu86-disk.config, emu86-rom.config, emu86-rom-full.config, blink16.config and swan.config for emulated and ROM targets.

The naming encodes the meaningful variables. The floppy size, the pc98 variants, whether you are on protected mode, and whether the target is an emulator or a ROM image.

The Dockerfile offers the container route for building without polluting a host. It is based on ubuntu:20.04, installs the build prerequisites, creates a non-root builder user with uid 1000, copies the source in and runs tools/build.sh to build the cross tooling. The remaining steps are deliberately left to the operator, with comments naming them.

make menuconfig
make all

After that, the results are collected from the image directory into a tarball and copied out of the container.

cd image && tar -cvzf binfiles.tar.gz *.bin
docker cp elks-dist:/elks/image/binfiles.tar.gz .

The apt list in the Dockerfile is the dependency set: texinfo, libncurses5-dev, bison, flex, bash, make, g++, git, libelf-dev, patch, xxd, ca-certificates, wget and mtools. mtools and xxd are there for manipulating disk images, which is consistent with the FAT and floppy targets.

Try it in a browser before committing hardware

The README offers a way to see ELKS without building or owning anything: a v86 emulator profile hosted at copy.sh, reachable in a browser. Login is root with no password, and the instructions say to go into the bin folder and try the available commands, then try nxtetris and press n to start the game.

That is a genuinely useful test for an evaluation, because it tells you the shape of the userland without any hardware.

For development there is a companion project, blink16, described as a visual 8086 emulator and debugger capable of booting the ELKS kernel for symbolic debugging, and also an emulator for ELKS executables. The presence of blink16.config in the ELKS repository root suggests the two are built together for at least some configurations.

The 8086 toolchain is a separate repository, ghaerr/8086-toolchain, described as a full C toolchain capable of running on Linux, macOS and natively on ELKS, with a C compiler and preprocessor, an as86 assembler, an ld86 linker, a disassembler, make and a complete C library. Running the toolchain on ELKS itself is the detail that closes the loop: once ELKS boots, it can build programs for itself.

The README also credits TK Chia's gcc-ia16, a GCC targeted at 8086, as maintained by that author and used for the ELKS kernel and all its applications. So there are two independent compiler routes into the same kernel, which matters if you need one of them to fail over.

Where ELKS is the wrong answer

The case against ELKS is not subtle: anything running on hardware with an MMU and more than a megabyte of RAM should use a real Linux, and if you need 32-bit or 64-bit, multitasking with protection, a modern filesystem with journaling, or a maintained package ecosystem, ELKS gives you none of it.

The practical risk for a new adopter is not capability, it is surface area. This is a kernel where a bug in a driver can cost you the only copy of your data, since the filesystem support is MINIX and MSDOS FAT rather than anything with journaling. Hardware support is per machine: the configuration files named after specific models are a reminder that this is a porting project, not a generic x86 kernel.

A middle path is to run ELKS under an emulator for development and debug with blink16, and only then move to physical hardware. Several videos in the README show exactly that, including booting on a 286 from a 1.44MB floppy, an Amstrad PC 2086, a NEC V30 based Epson portable, and ELKS on an ESP32 through an IBM PC emulator.

Documentation lives in three places: the Documentation folder with an index, the project wiki for how to use ELKS and technical tutorials, and BUILD.md for build instructions. Licensing is the custom one in the LICENSE file. Questions and patches go through GitHub issues.

Editorial conclusion

ELKS fits anyone reviving an 8086 class machine, an FPGA or SBC that needs a real kernel without an MMU, and it is genuinely usable today since v0.9.2 was released on 2026-09-06 with the last push on 2026-10-05. It does not fit modern server or desktop work, and it does not fit a team that wants a one command build, because the toolchain has to exist before make will run at all. Before starting, pick your config from the checked in files such as ibmpc-1440.config or pc98-1232.config rather than from menuconfig defaults, and confirm your target CPU is on the supported list, which runs from the 8086 through the 80286 and also covers NEC V20 and V30 parts.

Frequently asked questions

Official sources

1. ghaerr/elks on GitHub
2. Issues
3. README
4. Releases