I’ll be upfront about this one: fdformat is a command from an era of computing that’s genuinely gone. I still think it’s worth documenting properly, because it comes up in legacy system maintenance, retrocomputing hobby projects, industrial equipment that still reads floppies (yes, this is a real thing — plenty of CNC machines and older medical devices still take 3.5″ disks), and because understanding it teaches useful things about how low-level formatting differs from what mkfs does. I tried installing and running it directly on a current Ubuntu 24.04 system while writing this, and that experience itself is informative, so I’ll walk through that too.
What fdformat Does
fdformat performs a low-level format of a floppy diskette — it doesn’t write a filesystem the way mkfs does. Instead, it writes the physical track and sector layout onto the magnetic media itself: sector headers, gaps, and the raw addressable structure the floppy controller needs before any filesystem can be laid on top. Historically, the typical two-step process for preparing a blank floppy was:
fdformat /dev/fd0 # low-level format: lay down tracks and sectors
mkfs.msdos /dev/fd0 # write an actual FAT filesystem on top
This two-step model is unlike hard disks and SSDs, which arrive from the factory already low-level formatted, so on those devices you only ever run mkfs directly. Floppies were the one common consumer medium where both steps were routinely necessary and user-facing.
Historical Syntax
fdformat [ -n ] device
| Option | Description |
|---|---|
-n | Skip the verification pass after formatting, making the format faster but skipping the read-back check that confirms every sector is reliably writable/readable |
device | The floppy device node, e.g. /dev/fd0 (first floppy drive), /dev/fd0H1440 (explicitly 1.44MB HD format), /dev/fd0H720 (720KB) |
Device nodes historically encoded the format density directly in the name — /dev/fd0H1440 for a 3.5″ high-density 1.44 MB disk, /dev/fd0H720 for double-density 720 KB, /dev/fd0u1720 for non-standard user-defined geometries via setfdprm. This let you force a specific format regardless of what the disk’s physical HD-hole sensor reported.
What I Actually Found Testing This Today
I attempted to test fdformat directly rather than relying only on documentation. On a current Ubuntu 24.04 system:
$ which fdformat
(nothing found)
The classic fdformat binary shipped historically as part of util-linux, but it was removed from util-linux in the util-linux 2.29 era (released around 2017) specifically because floppy hardware had become vanishingly rare, and its low-level ioctl interface into the floppy driver was seen as unmaintained legacy weight.
I then installed the dedicated fdutils package, which still exists in Ubuntu’s repositories:
$ apt-get install -y fdutils
This installs a related but distinct set of tools — superformat, xdfformat, getfdprm, setfdprm — rather than a binary literally named fdformat. superformat is the modern successor with a similar role:
superformat [options] device [format-descriptor]
Even with these tools installed, actually running a format requires a real floppy controller and drive attached to /dev/fd0, which no cloud VM, container, or modern laptop has — there’s no physical hardware to test against in a sandboxed or virtualized environment, and this is true industry-wide, not a limitation specific to any one setup. I want to be transparent about that rather than fabricate output that would be misleading.
What the Command Would Actually Do (Documented Behavior)
Based on the tool’s documented behavior and man pages, a successful run against real floppy hardware looks like this:
$ fdformat /dev/fd0H1440
Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
Formatting ... done
Verifying ... done
If a bad sector is found during verification:
Verifying ... read: Input/output error
Skipping track 39, head 1
Bad tracks get marked and skipped rather than aborting the whole format, similar in spirit to how mkfs handles bad-block marking on other media via -c/badblocks integration.
How Low-Level Floppy Formatting Works Internally
A blank floppy diskette, magnetically, is just a spinning disk of ferric oxide with no inherent structure. The floppy disk controller (FDC), communicated with through the kernel’s floppy driver (drivers/block/floppy.c historically in the kernel tree), needs explicit sector boundary markers physically written onto the media before it can address anything by cylinder/head/sector.
fdformat issues an FDFMTBEG/FDFMTTRK/FDFMTEND sequence of ioctls to the floppy driver, which drives the controller to:
- Position the read/write head at each cylinder in turn
- Write an index pulse-synchronized sequence of sector ID fields (cylinder, head, sector number, sector size) followed by a data field filled with a fixed pattern, separated by inter-sector gaps, for every sector on that track
- Move to the next track and repeat, alternating heads for double-sided media
Once every track has this address structure, the disk exposes a flat, addressable sector space — exactly the same abstraction a hard disk already has natively — and only then can mkfs.msdos or any other filesystem builder treat it like an ordinary block device.
This is conceptually the ancestor of what happens invisibly at the factory for every hard disk and SSD you’ve ever used; floppies just made you do it yourself.
Practical Use Cases (Historical and Present-Day)
- Retrocomputing and vintage hardware preservation — people restoring old Amiga, DOS, or early Macintosh systems still need working blank floppies, often reformatted from old media with degraded low-level structure.
- Legacy industrial and medical equipment — some CNC controllers, embroidery machines, and older lab instruments still use 3.5″ floppies as their only removable media interface, and occasionally need reformatted disks when read/write errors accumulate.
- Digital archivists — museums and archival projects sometimes need to reformat and test floppy media as part of validating whether old disks are still physically readable before imaging them (usually with tools like
fdrawcmdor dedicated hardware like a Kryoflux, rather thanfdformatitself, for archival-grade imaging).
For virtually everyone else today, this command is something you’ll encounter only when reading old documentation or maintaining genuinely old systems.
Troubleshooting (as Documented Historically)
“No such device” on /dev/fd0 — no floppy controller detected, or the floppy kernel module isn’t loaded (modprobe floppy); on modern hardware, this almost always means there’s no physical floppy controller present at all — USB floppy drives use a different driver path (usb-storage, appearing as /dev/sdX) and don’t go through fdformat/the legacy floppy ioctls at all.
Format hangs or times out — worn drive belts, dirty read/write heads, or genuinely failing media; historically this was one of the most common “the disk is going bad” symptoms.
Verify pass reports scattered I/O errors across many tracks — indicates the diskette itself has degraded past usability; discard it rather than continuing to retry.
Works on /dev/fd0 but not /dev/fd0H1440 — the explicit density device node wasn’t created; check /dev node availability or fall back to setfdprm to manually define geometry before formatting.
Comparison with Related Commands
| Command | Role |
|---|---|
fdformat (legacy util-linux) | Low-level floppy format only |
superformat (fdutils package, modern) | Successor tool, supports extended/non-standard floppy formats beyond plain 1.44MB |
setfdprm / getfdprm | Manually set or query floppy drive parameters (geometry) when auto-detection fails |
mkfs.msdos | Writes the actual FAT filesystem on top of an already low-level-formatted floppy |
dd | Used today to image or restore entire floppy contents sector-by-sector for archival purposes, bypassing filesystem semantics entirely |
Distribution Compatibility
This is genuinely inconsistent across modern distributions, and worth checking explicitly rather than assuming:
- Ubuntu/Debian:
fdformatitself is gone fromutil-linux; install thefdutilspackage forsuperformatand related tools instead. - RHEL/Fedora/CentOS: floppy support tooling was dropped from base repos years ago; EPEL or manual compilation may be needed for
fdutilsequivalents. - Arch Linux:
fdutilsis available in the AUR, not the main repositories. - Older LTS distributions (pre-2017 util-linux): still ship the original
fdformatbinary directly.
If you’re maintaining genuinely legacy infrastructure, I’d recommend pinning a specific older distribution release known to include the original tool rather than assuming any current mainstream distro still ships it out of the box.
Security Implications
Low-level formatting is a fully destructive, irreversible operation on the target media — there’s no meaningful “undo,” and unlike a filesystem-level mkfs where data recovery tools sometimes reconstruct content from residual blocks, a low-level reformat rewrites the physical sector structure itself, making the previous data’s recoverability essentially nil. For archival or forensic contexts, always image the disk first (dd if=/dev/fd0 of=image.img) before any low-level format is even considered.
Floppy Density Standards and Why Device Naming Mattered
Understanding why fdformat needed density-specific device nodes like /dev/fd0H1440 requires a bit of background on how floppy media varied. Over the format’s lifespan, several physically distinct standards existed, and a controller couldn’t always auto-detect which one was inserted purely from the drive’s mechanical sensors:
| Format | Capacity | Tracks | Sectors/Track |
|---|---|---|---|
| 5.25″ DD | 360 KB | 40 | 9 |
| 5.25″ HD | 1.2 MB | 80 | 15 |
| 3.5″ DD | 720 KB | 80 | 9 |
| 3.5″ HD | 1.44 MB | 80 | 18 |
| 3.5″ ED | 2.88 MB | 80 | 36 |
The 3.5″ HD drive’s physical “HD hole” sensor could usually distinguish 720KB media from 1.44MB media automatically, but non-standard formats (like the 1.72MB “DMF” format Microsoft used for some distribution media, or various “extra density” tricks that squeezed more capacity out of standard disks by writing more sectors per track than the media was rated for) required explicitly forcing a specific geometry via setfdprm before formatting, since auto-detection had no way to know the operator intended a non-standard layout. This is exactly the class of problem /dev/fd0uNNNN user-defined device nodes existed to solve.
Why Floppies Needed Both Steps and Hard Disks Didn’t
It’s worth explaining directly why this two-step formatting model was specific to floppies rather than a general Linux concept. Hard disk platters and modern SSDs are low-level formatted once, at the factory, using specialized manufacturing equipment that writes the servo tracking information and sector structure with a precision no end-user tool could replicate — this is why you’ll never see a consumer-facing “low-level format” command for a modern SATA or NVMe drive; the closest analogous operation (hdparm --security-erase for genuine secure erase, or a SCSI/NVMe “format” command that resets logical block mappings) is a completely different, much narrower operation than what floppy low-level formatting did. Floppy media, by contrast, was cheap, commodity, unformatted-by-default magnetic film that genuinely needed the end user’s drive to write its own addressable structure before first use — an artifact of the economics and manufacturing simplicity of that specific medium, not a general pattern that carried forward to any other storage type Linux has supported since.
Modern Alternatives for Reading Old Floppy Media
For anyone actually working with legacy floppy disks today — archivists, retrocomputing hobbyists, or someone who just found a box of old disks — it’s worth knowing the tooling landscape has moved well past fdformat‘s original scope. Dedicated hardware like the Kryoflux or Greaseweazle boards read the raw magnetic flux transitions directly, bypassing the standard floppy controller’s sector-based abstraction entirely, which allows recovery of data from disks with non-standard or copy-protected formats that a plain Linux floppy driver was never designed to interpret correctly. For straightforward standard-format disks on genuinely working consumer floppy hardware, the simpler path is usually just imaging the whole disk with dd:
dd if=/dev/fd0 of=disk_image.img bs=512 conv=noerror,sync
conv=noerror,sync tells dd to continue past read errors on bad sectors rather than aborting, padding failed reads with zero bytes to keep the image’s overall structure intact — useful specifically because aging floppy media frequently develops a handful of bad sectors without being completely unreadable overall, and a partial image is often still far more useful than no image at all.
Summary
fdformat belongs to a two-step formatting model — physical low-level structure first, filesystem second — that made sense for removable magnetic media without factory-level formatting and has no real equivalent need on modern hard disks or SSDs. I documented it here based on its well-established historical behavior and man page specification, since I don’t have physical floppy hardware available to demonstrate live output, and I think that honesty matters more than faking a transcript. If you’re working with real floppy hardware today, fdutils‘ superformat is the actively maintained tool to reach for.
References
- util-linux git history — removal of
fdformat: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/ - fdutils project (superformat, setfdprm, getfdprm): https://fdutils.linux.lu/
- Linux Kernel Documentation — floppy driver: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/index.html
- Debian Package Archive — fdutils: https://packages.debian.org/fdutils