This could be increased noticeably by using one of the common extended floppy formats. The 21-sectors-per-track format used by MS¹ for Windows 95's floppy distribution was widely supported enough by drives (and found to be reliable enough on standard disks) that they considered it safe for mass use, and gave 1680KB instead of the 1440Kb offered by the standard 18-sector layout. The standard floppy formatting tools for Linux support creating such layouts.
--------
[1] There was some suggestion² that MS invented the extended floppy format, they were sometimes called “windows format”, but it³ had been used elsewhere for some time before MS used them for Windows and Office.
[2] I'm not sure if this came from MS themselves, or was invented by the tech press.
[3] and even further extended formats, including 1720KByte by squeezing in two extra tracks as well as more data per track which IIRC was used for OS/2 install floppies.
Sadly, it does not seem to boot on my 486 DX2, I even stuffed 32M of RAM into the machine (8*4M, maximum the mainboard supports), more than the recommended 20M.
I have copied the floppy image from the site. It churns for about a minute and a half, loading kernel and initrd, then says "Booting kernel failed: Invalid Argument" and drops into SYSLINUX prompt.
EDIT: I tried a few more floppies to rule that out as the cause of the problem.
Here are some screenshots: https://imgur.com/a/floppinux-0-3-1-Mdh1c0w
EDIT 2: I cloned SYSLINUX, checked out the specific commit and did some prodding around.
The function `bios_boot_linux` in `com32/lib/syslinux/load_linux.c` initializes errno to EINVAL. Besides sanity checking the header of the kernel image, there are a few other error paths that also `goto bail;` without changing errno.
Those other error paths all seem to be related to handling the memory map. I know that the BIOS in my machine does not support the E820h routine. I have a hunch that this might be the reason why it fails.
The website has an image gallery where people ran it on actual hardware: https://krzysztofjankowski.com/floppinux/floppinux-in-the-wi...
Most of those machines seem to be newer systems which probably support E820h, except for another 486 DX2 with a similar vintage as mine, that also failed to boot.
From the main page:
As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386. AntiX is a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian. So, this project stands on the shoulders of giants. In other words, DSL 2024 is a humble little project!
Though it may seem comparably ridiculous that 700MB is small in 2024 when DSL was 50MB in 2002, I’ve done a lot of hunting to find small footprint applications, and I had to do some tricks to get a workable desktop into the 700MB limit. To get the size down the ISO currently reduced full language support for German, English, French, Spanish, Portuguese and Brazilian Portuguese (de_DE, en_AU, en_GB, en_US, es_ES, fr_FR, es_ES, pt_PT, & pt_BR ). I had to strip the source codes, many man pages, and documentation out. I do provide a download script that will restore all the missing files, and so far, it seems to be working well.
As an alternative, isn't ext2 smaller by having no FAT tables?
I don't know if that's also true for data integrity on physical magnetic media. FAT12 is not a journaling filesystem. On a modern drive, a crash during a write is at best, annoying while on a 3.5" floppy with a 33mhz CPU, a write operation blocks for a perceptible amount of time. If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone. The article mentions sync, but sync on a floppy drive is an agonizingly slow operation that users might interrupt.
Given the 253KiB free space constraint, I wonder if a better approach would be treating the free space as a raw block device or a tiny appended partition using a log-structured filesystem designed for slow media (like a stripped down JFFS2 or something), though that might require too many kernel modules.
Has anyone out there experimented with appending a tar archive to the end of the initramfs image inplace for persistence, rather than mounting the raw FAT filesystem? It might be safer to serialize writes only on shutdown, would love more thoughts on this.
https://www.zelow.no/floppyfw/
to setup small router on 486 with 12 MB ram and run flawless. Later i get Linksys WRT54GL and decommissioned that machine.
The two main problems I ran into were 1) software support at the application layer, and 2) video driver support. There is a herculean effort on the part of package maintainers to build software for distros, and no one has been building 32 bit version of software for years, even if it is possible to build from source. There is only a very limited set of software you can use, even CLI software because so many things are built with 64 bit dependencies. Secondly, old video card drivers are being dropped from the kernel. This means all you have is basic VGA "safe-mode" level support, which isn't even fast enough to play an MPEG2. My final try was to install Debian 5, which was period correct and had support for my hardware, but the live CDs of the the time were not hybrid so the ISO could not boot from USB. I didn't have a burner so I finally gave up.
So I think these types of projects are fun for a proof of concept, but unfortunately are never going to give life to old computers.
And they used to fail all the time, especially when you had something that spanned more than a single disk.
X disks were X11. There were also the A,B, C etc disks.
Then there was the Coherent install, with massive manual on ultra thin paper with the shell on the front.
The HDD was borked but it had a 3.5" bay that worked, so I got a floppy-based distro running on it. I later replaced the drive and then made the mistake of attempting to compile X11 on it. Results were... mixed.
https://web.archive.org/web/20240901115514/https://pupngo.dk...
Makes sense, great point. I would rather use a second drive for the write disk space, if possible (I know how rare it's now to have two floppy drives, but still).
This isn't true, I commented lower in the thread, but FAT keeps a backup table, and you can use that to restore the disk.
This statement must be Linux-only
Pre-compiled packages for i386 are still available for all versions of NetBSD including the current one
I still compile software for i386 from pkgsrc
https://ftp.netbsd.org/pub/pkgsrc/current/
NB. I'm not interested in graphical software, I prefer VGA textmode
It can boot from a floppy or from a CD drive, and it lets you chainload into a live usb even on old computers.
I used it to boot from CD from a floppy in an old Pentium MMX and it worked great (although slow, of course)
Whish coil whine was configurable :)
For those who are curious, Alpine was the recommended distro as I went through various reviews. I don't know how reliable that advice is.
https://news.ycombinator.com/item?id=38059961
https://news.ycombinator.com/item?id=27249075
That was 1999 and I never saw anything like that afterwards.
Now you have ;-)
My first thought: How about using a current computer to run qemu then mounting the Lenny iso as an image and installing to a qemu hard drive? Then dd the hard drive image to your 32bit target. (That might need access to a hard drive caddy depending on how you can boot the 32bit target machine, so a 'hardware regress' I suppose).
My second thought: If target machine is bootable from a more recent live linux, try a debootstrap install of a minimal Lenny with networking (assuming you can connect target machine to a network, I'm guessing with a cable rather than wifi). Reboot and install more software as required.
1) mark blocks allocated in first FAT
If a crash occurs here, then data written is incomplete, so write FAT1 with data from FAT2 discarding all changes.
2) write data in sectors
If a crash occurs here, same as before, keep old file size.
3) update file size in the directory
This step is atomic - it's just one sector to update. If a crash occurs here (file size matches FAT1), copy FAT1 to FAT2 and keep the new file size.
4) mark blocks allocated in the second FAT
If a crash occurs here, write is complete, just calculate and update free space.
5) update free spaceIt baffles me how usable Office 97 still. I was playing with it recently in a VM to see if it worked as well as I remembered, and it was amazing how packed with features it is considering it's nearing on thirty. There's no accounting for taste but I prefer the old Office UI to the ribbon, there's a boatload of formatting options for Word, there's 3D Word Art that hits me right in the nostalgia, Excel 97 is still very powerful and supports pretty much every feature I use regularly. It's obviously snappy on modern hardware, but I think it was snappy even in 1998.
I'm sure people can enumerate here on the newer features that have come in later editions, and I certainly do not want to diminish your experience if you find all the new stuff useful, but I was just remarkably impressed how much cool stuff was in packed into the software.
Nope, that’s a modern problem. That’s what happens when the js-inmates run the asylum. We get shitty bloated software and 8300 copies of a browser running garage applications written by garbage developers.
I can’t wait to see what LLMs do with that being the bulk of their training.
Exciting!
I once tried to use it as a GUI daily driver on my work laptop (since I was already using it for containers and VMs at work) and found that stretched it a bit too far out of its speciality. It definitely had the necessary packages, just with a lot of rough edges and increased rate of problems (separate from glibc, systemd, or other expected compatibility angles). Plus the focus on having things be statically linked makes really wide (lots of packages) installs negated any space efficiency gains it had.
It's really astonishing how full-featured it all was, and it was running on those Pentium machines that had a "turbo" button to switch between 33 and 66 MHz and just a few MBs of RAM.
It definitely was snappy. I used it on school computers that were Pentium (1?) with about as much RAM as my current L2 cache (16MB). Dirty rectangles and win32 primitives. Very responsive. It also came with VB6 where you could write your own interpreted code very easily to do all kinds of stuff.
It's basically what people used before USB sticks. But it was also the storage medium that software was sold on, before CD-ROMs became widespread.
With memory prices skyrocketing, I wonder if we will see a freeze in computer hardware requirements for software. Maybe it's time to optimize again.
(edit to say I'm obviously ignoring i8n etc.)
With the small caveat that I only use Word, it runs perfectly in WINE and has done for over a decade. I use it on 64-bit Ubuntu, and it runs very well: it's also possible to install the 3 service releases that MS put out, and the app runs very quickly even on hardware that is 15+ years old.
The service packs are a good idea. They improve stability, and make export to legacy formats work.
WINE works better than a VM: it takes less memory, there's no VM startup/shutdown time, and host integration is better: e.g. host filesystem access and bidirectional cut and paste.
I am now starting to wonder how much of it has to do with network access to Sharepoint and telemetry data that most likely didn't exist in the Office 97 dial-up era.
Features-wise - I doubt there is a single feature I use (deliberately) today in Excel or Word that wasn't available in Office 97.
I'd happily suffer Clippy over Co-Pilot.
Alternatively you may have accidently built a great machine for installing FreeDOS to run old DOS games/applications. It does install from USB, but needs BIOS so can't run it on modern PC hardware.
That seems odd? Debian 12 Bullseye (oldstable) has fully supported i386 port. I would expect it to run reasonably well on late 32 bit era systems (Pentium4/AthlonXP)
(That mail also mentions the floppy driver is "basically orphaned" though. But evidently it's still there and builds.)
Maybe you're thinking of the floppy tape (ftape) driver, which was removed back in the 2.6.20 kernel. Though there's a project keeping an out-of-tree version of it working with recent kernels at https://github.com/dbrant/ftape
Are you from South Africa? I understand it was the standard slang name there -- and nowhere else, because of the double entendre.
The Linux kernel drops i486 support in 6.15 (released May 2025), so 6.14 (released March 2025) is the latest version with full compatibility.
#inicio de fichero
--format=bestvideo[height<=?480][fps<=?30]+bestaudio/best
#fin de fichero
My ~/.config/mpv/config#inicio
ytdl-format=bestvideo[height<=?480][fps<=?30]+bestaudio/best
ao=sndio
vo=gpu,xv
audio-pitch-correction=no
quiet=yes
pause=no
profile=fast
vd-lavc-skiploopfilter=all
#demuxer-cache-wait=yes
#demuxer-max-bytes=4MiB
#fin
Usage: mpv $YOUTUBE_URLUpgrade ASAP.
Yeah you can get machines which are higher specced easily enough, but they’re usually at the upper end of the average consumers budget.
Meanwhile my home PC starts blowing whenever I fire up a video game.
Rookie developers who use hundreds of node modules or huge CSS frameworks are ruining performance and hurt the environment with bloated software that consumes energy and life time.
It's an optional install. You can just click Custom, untick "Office Assistant" and other horrid bits of bloat like "Find Fast" and "Word Mail in Outlook" and get rid of that stuff.
December 21, 2025 | back to home
FLOPPINUX was released in 2021. After four years people find it helpful. Because of that I decided to revisit FLOPPINUX in 2025 and make updated tutorial. This brings bunch of updates like latest kernel and persistent storage.
Think of this as Linux From Scratch but for making single floppy distribution.
It is meant to be a full workshop (tutorial) that you can follow easily and modify it to your needs. It is a learning exercise. Some base Linux knowledge is needed.
The final distribution is very simple and consists only of minimum of tools and hardware support. As a user you will be able to boot any PC with a floppy drive to a Linux terminal, edit files, and create simple scripts. There is 264KB of space left for your newly created files.
The Linux kernel drops i486 support in 6.15 (released May 2025), so 6.14 (released March 2025) is the latest version with full compatibility.
This time I will do everything on Omarchy Linux. It is 64-bit operating system based on Arch Linux. Instructions should work on all POSIX systems. Only difference is getting needed packages.
Create directory where you will keep all the files.
mkdir ~/my-linux-distro/
BASE=~/my-linux-distro/
cd $BASE
You need supporting software to build things. This exact list may vary depending on the system you have.
Install needed software/libs. On Arch/Omarchy 3.1:
sudo pacman -S ncurses bc flex bison syslinux cpio
Cross-compiler:
wget https://musl.cc/i486-linux-musl-cross.tgz
tar xvf i486-linux-musl-cross.tgz
rm i486-linux-musl-cross.tgz
86Box is also good but slower. Bochs is the best but for debugging, not needed here.
For emulation I will be using qemu.
sudo pacman -S qemu-full
Get the sources for the latest compatible kernel 6.14.11:
git clone --depth=1 --branch v6.14.11 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
Now, that you have them in linux/ directory lets configure and build our custom kernel. First create tiniest base configuration:
make ARCH=x86 tinyconfig
This is a bootstrap with absolute minimum features. Just enough to boot the system. We want a little bit more.
Add additonal config settings on top of it:
make ARCH=x86 menuconfig
Important: Do not uncheck anything in options unless specified so. Some of those options are important. You can uncheck but on your own risk.
From menus choose those options:
Exit configuration (yes, save settings to .config).
Time for compiling!
make ARCH=x86 bzImage -j$(nproc)
This will take a while depending on the speed of your CPU. In the end the kernel will be created in arch/x86/boot/ as bzImage file.
Move kernel to our main directory and go back to it:
mv arch/x86/boot/bzImage ../
cd ..
Without tools kernel will just boot and you will not be able to do anything. One of the most popular lightweight tools is BusyBox. It replaces the standard GNU utilities with way smaller but still functional alternatives, perfect for embedded needs.
Get the 1.36.1 version from busybox.net or Github mirror. Download the file, extract it, and change directory:
Remember to be in the working directory.
wget https://github.com/mirror/busybox/archive/refs/tags/1_36_1.tar.gz
tar xzvf 1_36_1.tar.gz
rm 1_36_1.tar.gz
cd busybox-1_36_1/
As with kernel you need to create starting configuration:
make ARCH=x86 allnoconfig
You may skip this following fix if you are building on Debian/Fedora
Fix for Arch Linux based distributions:
sed -i 's/main() {}/int main() {}/' scripts/kconfig/lxdialog/check-lxdialog.sh
Now the fun part. You need to choose what tools you want. Each menu entry will show how much more KB will be taken if you choose it. So choose it wisely :) For the first time use my selection.
Run the configurator:
make ARCH=x86 menuconfig
Choose the following options. Remember to do not uncheck anything if not stated here.
Now exit with save config.
Our target system needs to be 32-bit. To compile it on 64-bit system we need a cross compiler. You can setup this by hand in the menuconfig or just copy and paste those four lines.
Setup paths:
sed -i "s|.*CONFIG_CROSS_COMPILER_PREFIX.*|CONFIG_CROSS_COMPILER_PREFIX=\"${BASE}/i486-linux-musl-cross/bin/i486-linux-musl-\"|" .config
sed -i "s|.*CONFIG_SYSROOT.*|CONFIG_SYSROOT=\"${BASE}/i486-linux-musl-cross\"|" .config
sed -i "s|.*CONFIG_EXTRA_CFLAGS.*|CONFIG_EXTRA_CFLAGS=-I$BASE/i486-linux-musl-cross/include|" .config
sed -i "s|.*CONFIG_EXTRA_LDFLAGS.*|CONFIG_EXTRA_LDFLAGS=-L$BASE/i486-linux-musl-cross/lib|" .config
Build tools and create base filesystem (“install”). It will ask for options, just press enter for default for all of them.
make ARCH=x86 -j$(nproc) && make ARCH=x86 install
This will create a filesystem with all the files at **_install/**. Move it to our main directory. I like to rename it to.
Lastly to to that new directory.
mv _install ../filesystem
cd ../filesystem
You got kernel and basic tools but the system still needs some additional directory structure.
This created minimum viable directory structure for satisfying the basic requirements of a Linux system.
Remember to be in the filesystem/ directory.
mkdir -pv {dev,proc,etc/init.d,sys,tmp,home}
sudo mknod dev/console c 5 1
sudo mknod dev/null c 1 3
Next step is to add minimum configuration files. First one is a welcome message that will be shown after booting.
Here is the first real opportunity to go wild and make this your own signature.
cat >> welcome << EOF
Your welome message or ASCII art.
EOF
Or download my welcome file.
wget https://krzysztofjankowski.com/floppinux/downloads/0.3.1/welcome
It looks like that:
$ cat welcome
_________________
/_/ FLOPPINUX /_/;
/ ' boot disk ' //
/ '------------' //
/ .--------. //
/ / / //
.___/_________/__// 1440KiB
'===\_________\==' 3.5"
_______FLOPPINUX_V_0.3.1 __________________________________
_______AN_EMBEDDED_SINGLE_FLOPPY_LINUX_DISTRIBUTION _______
_______BY_KRZYSZTOF_KRYSTIAN_JANKOWSKI ____________________
_______2025.12 ____________________________________________
Back to serious stuff. Inittab tells the system what to do in critical states like starting, exiting and restarting. It points to the initialization script rc that is the first thing that our OS will run before dropping into the shell.
Create an inittab file:
cat >> etc/inittab << EOF
::sysinit:/etc/init.d/rc
::askfirst:/bin/sh
::restart:/sbin/init
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r
EOF
And the init rc script:
cat >> etc/init.d/rc << EOF
#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
mdev -s
ln -s /proc/mounts /etc/mtab
mkdir -p /mnt /home
mount -t msdos -o rw /dev/fd0 /mnt
mkdir -p /mnt/data
mount --bind /mnt/data /home
clear
cat welcome
cd /home
/bin/sh
EOF
Make the script executable and owner of all files to root:
chmod +x etc/init.d/rc
sudo chown -R root:root .
Compress this directory into one file. Then go back to working directory.
find . | cpio -H newc -o | xz --check=crc32 --lzma2=dict=512KiB -e > ../rootfs.cpio.xz
cd ..
Create booting configuration.
Another place to tweak parameters for your variant. Text after SAY is what will be displayed on the screen as first, usualy a name of the OS.
The tsc=unstable is useful on some (real) computers to get rid of randomly shown warnings about Time Stamp Counter.
Remember to be in the working directory.
cat >> syslinux.cfg << EOF
DEFAULT floppinux
LABEL floppinux
SAY [ BOOTING FLOPPINUX VERSION 0.3.1 ]
KERNEL bzImage
INITRD rootfs.cpio.xz
APPEND root=/dev/ram rdinit=/etc/init.d/rc console=tty0 tsc=unstable
EOF
Make it executable:
chmod +x syslinux.cfg
Create sample file
To make the system a little bit more user friendly I like to have a sample file that user will be able to read and edit. You can put anything you want in it. A simple help would be also a good idea to include.
cat >> hello.txt << EOF
Hello, FLOPPINUX user!
EOF
Filesystem is ready. Final step is to put this all on a floppy!
First we need an empty file in exact size of a floppy disk. Then format and make it bootable.
Create empty floppy image:
dd if=/dev/zero of=floppinux.img bs=1k count=1440
Format it and create bootloader:
mkdosfs -n FLOPPINUX floppinux.img
syslinux --install floppinux.img
Mount it and copy syslinux, kernel, and filesystem onto it:
sudo mount -o loop floppinux.img /mnt
sudo mkdir /mnt/data
sudo cp hello.txt /mnt/data/
sudo cp bzImage /mnt
sudo cp rootfs.cpio.xz /mnt
sudo cp syslinux.cfg /mnt
sudo umount /mnt
Done!
It’s good to test before wasting time for the real floppy to burn.
Boot the new OS in qemu:
qemu-system-i386 -fda floppinux.img -m 20M -cpu 486
If it worked that means You have successfully created your own distribution! Congratulations!
The floppinux.img image is ready to burn onto a floppy and boot on real hardware!
Change XXX to floppy drive name in your system. In my case it is sdb. Choosing wrongly will NUKE YOUR PARTITION and REMOVE all of your files! Think twice. Or use some GUI application for that.
sudo dd if=floppinux.img of=/dev/XXX bs=512 conv=notrunc,sync,fsync oflag=direct status=progress
After 5 minutes I got freshly burned floppy.
cat - display file contentscp - copy files and directoriesmv - move/rename files and directoriesrm - remove files and directoriesls - list directory contentsmkdir - creates directorydf -h - display filesystem disk space usagesync - force write of buffered data to disk - use this after any changes to the floppy filesystemmount - mount filesystemsumount - unmount filesystemsecho - display text outputmore - page through text outputclear - clear terminal screentest - evaluate conditional expressionsvi - text editorBut otherwise, yes, Debian 12 should work fine as you say. Not so long ago I installed it on an old Pentium M laptop I had lying around. Did take some tweaking, turned out that the wifi card didn't support WPA2/3 mixed mode which I had configured on my AP, so I had to downgrade security for the experiment. But video was hopeless, it couldn't even play 144p videos on youtube without stuttering. Maybe the video card (some Intel thing, used the i915 driver) didn't have HW decoding for whatever video encoder youtube uses nowadays (AV1?), or whatever.
A fella can dream, anyways.
Yes, soft updates style write ordering can help with some of the issues, but the Linux driver doesn't do that. And some of the issues are essentially unavoidable, requiring a a full fsck on each unclean shutdown.
https://www.popularmechanics.com/technology/gadgets/a23139/c...
Sarge dropped i386, Squeeze i486
1) Allocate space in FAT#2, 2) Write data in file, 3) Allocate space in FAT#1, 4) Update directory entry (file size), 5) Update free space count.
Rename in FAT is an atomic operation. Overwrite old name with new name in the directory entry, which is just 1 sector write (or 2 if it has a long file name too).
The CPU will be struggling with most modern video formats including h.264.
In general "what DOS did" doesn't cut for a modern system with page and dentry caches and multiple tasks accessing the filesystem without completely horrible performance. I would be really surprised if Windows handled all those cases right with disk caching enabled.
While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.