Floppinux – An Embedded Linux on a Single Floppy, 2025 Edition
Nostalgia and historical context
- Many reminisce about the physicality of floppies: drive noise, multi‑disk installs (Slackware on dozens of disks), and classic “demo” OSes like the QNX GUI-on-a-floppy and MenuetOS/KolibriOS.
- People recall floppy‑based Linux distros and router/firewall systems (e.g., floppyfw, CoyoteLinux, muLinux, Tom’s Root Boot) and how 486/Pentium‑era machines served as routers and gateways.
- Some note the floppy as an “iconic unit”: just big enough to be useful, small enough to make fitting a real OS a serious challenge, unlike 700MB CD images.
Technical constraints and clever tricks
- The described persistence trick—mounting the FAT filesystem read‑write and bind‑mounting it as home—is praised as a space‑saving hack, though some prefer a second floppy for writes.
- Others suggest avoiding FAT entirely: treat free space as a raw block area, or append data (e.g., a tar archive) to the initramfs and only serialize on shutdown.
- Extended floppy formats (e.g., 21 sectors/track for ~1.68MB) are proposed to gain extra space; Linux tools can create these formats.
- Questions arise about whether formatting is needed at all; some speculate about directly loading the kernel from raw sectors and embedding the command line.
Filesystem robustness and FAT vs journaling
- One side argues journaling is overrated and that FAT, widely used in embedded devices, is “good enough” if drivers are careful and fsck runs after failures.
- Others counter that without journaling, mid‑operation crashes can easily leave inconsistent metadata (e.g., broken renames, mismatched directory entries/FAT chains), requiring full checks.
- There’s detailed debate on how DOS historically ordered FAT writes (two FAT copies, directory update last) vs how modern Linux VFAT drivers actually behave; consensus is that mainline Linux does not implement the more careful strategy.
Old hardware, 32‑bit support, and practicality
- Several describe trying to revive 32‑bit or even 386/486 systems and finding that hardware power isn’t the main barrier; modern software stacks and drivers have largely left them behind.
- Problems cited: lack of modern 32‑bit binaries, dropped video drivers (leaving only slow VGA), non‑hybrid ISOs that don’t boot from USB, and difficulty playing even low‑res video.
- Some recommend NetBSD/OpenBSD or very small distros (e.g., delicate Linux, busybox‑based setups) for such machines; others note that “i386” in distro docs no longer means 386/486‑class CPUs are truly supported.
Kernel, floppy, and compatibility issues
- Contrary to some memories, Linux still includes a floppy driver, though it’s described as “basically orphaned.”
- i486 support is slated to be dropped in kernel 6.15; some suggest just using a still‑supported LTS like 6.12 rather than backporting.
- One report says Floppinux fails to boot on a real 486 DX2, apparently due to BIOS memory map (E820h) assumptions in SYSLINUX; works on newer systems but not certain older ones.
Motivations and relevance
- Some question the point of a floppy‑based Linux in 2025 given scarce hardware; others frame it as a pure challenge and learning project, akin to climbing an already‑climbed mountain.
- A recurring theme is affection for small, efficient systems in contrast to perceived modern bloat, even if projects like Floppinux are mostly nostalgic and educational rather than practically useful.