Floppy Driver Update Ready For Linux 6.2 - Still Being Maintained In 2023

[ssokolow]

No clue. I do stuff with floppies now and then... but I use an archival/forensic floppy controller (eg. KryoFlux, Greaseweazle, FluxEngine) which is a USB device controlled by userland software.

[Eirikr1848]

**Anyone know the state of floppy support in 2024?**

I haven't seen any articles newer than 2022 about this topic. It seems my encounters with floppy disks were pretty much zero from 1999 until now.

I'm currently working on:

• Creating D64 disk images for a Commodore 1541 floppy drive (recapped, rebuilt Commodores).
• Making Toshiba floppy restore images for older laptops (8088/286/386/486)
• benchmarking MS-DOS performance vs FreeDOS and SvarDOS.
• Performing data migration from floppy disks.
• Archiving individuals’ floppy disk histories to finetune LLMs so they can "chat with themselves" using their own data from back in the day.

However, I keep running into a consistent issue:
Every time I insert a floppy disk, the system locks up entirely, requiring a hard reboot.

I shall indeed run a stack trace to further investigate and will report the findings to the appropriate channels.

Question:
Has anyone else encountered similar issues with floppy support in modern systems? Wondering if this is a “me issue” or a broader issue.

[Developer12]

ssokolow Developer12 I think you're both ranging away from my point. I agree that having a working driver is good thing. My assertion is only that you do not have to have an older system with a floppy controller in it to be able to read and write floppies. Yes, the workflow is different, you're not just inserting the media, mounting it, reading/writing/modifying what you need, and unmounting it. You have to image the media, convert it to a block file image of the media, mount that on the loop interface, then do your read/write/modify step, unmount the loop, convert the image back to flux, write the physical media. Nothing that can't also be automated with a script.

If you're moving the disc back and forth daily, this will be a bit of a burden, but if you're doing that, you really need to look into a hardware floppy emulator because the amount of wear you're putting on that system will cause it to fail. But, in the case if needing to deal with a floppy monthly or annually, this method would be just as easy and probably superior as the whole media gets rewritten and there's no jitter between the sector headers and the data because the image gets written 'perfect' instead of how it happens with a floppy controller on a physical drive.

Is it possible to read/write files in this way? yes. Is it convenient enough to inflict this on your employees? no.

If you go waaaaaaay back to my original post, you'll note that I gave another solution: A "chain of fools" where you use a string of two or more computers (of varying age) to copy files onto and off of the disk, shuffling between multiple formats.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1360535-floppy-driver-update-ready-for-linux-6-2-still-being-maintained-in-2023?p=1360545#post1360545

The fundamental requirement (as I discussed) is to have people copy files onto and off of floppy disks for running vintage equipment when the files are present on modern IT infrastructure. Being able to insert the floppy into a mid-2000s machine with a native floppy drive, running a modern OS, and just drag the files across is the optimal solution. It however requires working drivers.

While there are LOTS of ways it's *physically* possible to put some files on a floppy disk, a chain of fools and complicated floppy imaging equipment both fail the human factors requirement.

[willmore]

ssokolow Developer12 I think you're both ranging away from my point. I agree that having a working driver is good thing. My assertion is only that you do not have to have an older system with a floppy controller in it to be able to read and write floppies. Yes, the workflow is different, you're not just inserting the media, mounting it, reading/writing/modifying what you need, and unmounting it. You have to image the media, convert it to a block file image of the media, mount that on the loop interface, then do your read/write/modify step, unmount the loop, convert the image back to flux, write the physical media. Nothing that can't also be automated with a script.

If you're moving the disc back and forth daily, this will be a bit of a burden, but if you're doing that, you really need to look into a hardware floppy emulator because the amount of wear you're putting on that system will cause it to fail. But, in the case if needing to deal with a floppy monthly or annually, this method would be just as easy and probably superior as the whole media gets rewritten and there's no jitter between the sector headers and the data because the image gets written 'perfect' instead of how it happens with a floppy controller on a physical drive.

[ssokolow]

People don't need this for archival or forensic purposes. They need to mount the floppy disk and copy files across. That's why they need continued support for floppy drives.

*nod* I'm just saying that it's less convenient because that use-case isn't what those things are designed for. It's like complaining about the gas mileage of a big, heavy industrial haulage vehicle when you're using it as a residental vehicle. Sure, you can do it... but you have no right to then complain about it.

(In other words, I did a sloppy job of elaborating on your argument. I didn't meant to dispute it.)

[Developer12]

It's not meant to be. It's what's known as an "archival/forensic" floppy controller... a class of devices which prioritize things like write-protect jumpers and being able to make low-level flux images of disks to preserve things like copy protection schemes intact for future analysis and/or authentic emulation.

...something which I like, since I never have to worry about a Thumbs.db or .DS_Store or .directory or changes to file metadata trashing pristine-ness of a vintage disk where the publisher didn't bother to get disks with the write protect slider omitted and someone (eg. my young self) used it as a fidget toy.

People don't need this for archival or forensic purposes. They need to mount the floppy disk and copy files across. That's why they need continued support for floppy drives.

[ssokolow]

You can do that, but it's not nearly as convenient as simply mounting the floppy to the filesystem as a drive.

It's not meant to be. It's what's known as an "archival/forensic" floppy controller... a class of devices which prioritize things like write-protect jumpers and being able to make low-level flux images of disks to preserve things like copy protection schemes intact for future analysis and/or authentic emulation.

...something which I like, since I never have to worry about a Thumbs.db or .DS_Store or .directory or changes to file metadata trashing pristine-ness of a vintage disk where the publisher didn't bother to get disks with the write protect slider omitted and someone (eg. my young self) used it as a fidget toy.

[Developer12]

While I agree with your logic, there is another way. You can interact with a floppy drive on a modern (USB and newer I/O only) machine without this driver at all. There are a number of devices which allow you to control a floppy mechanism with a USB microcontroller such that you can read and write discs without an actual floppy controller. The one I'm most familiar with is https://github.com/keirf/greaseweazle. It allows you to graft something as simple, cheap, and readily available as a Blue Pill board to a 3.5", 5", or even 8" floppy drive to read and write media. Better yet, it has none of the sector and timing limitations of classic floppy controllers. The hardware works at the flux level and all the data format and sector encoding is done in software.

You can do that, but it's not nearly as convenient as simply mounting the floppy to the filesystem as a drive.

[edwaleni]

There are many legacy PBX style phone switches that came out of Y2K alive with their floppy drives intact. Some of them run Unix System V, some BSD.

Even though they could probably convert them to Asterisk running on a RaspPi by now, they soldier on.

[willmore]

Every time the floppy drivers come up people keep asking why a modern kernel should care.

The answer is that any old, large equipment that *has* to use floppy drives at some point has to interact with your modern IT. That means some mid 2000's box somewhere with a floppy drive, subject to the same IT policies as everything else and thus running a modern well-supported OS. Nobody wants to play chain of fools through three different computers just to get an SVG that came in over email from a client loaded into the ancient plasma cutter.

While I agree with your logic, there is another way. You can interact with a floppy drive on a modern (USB and newer I/O only) machine without this driver at all. There are a number of devices which allow you to control a floppy mechanism with a USB microcontroller such that you can read and write discs without an actual floppy controller. The one I'm most familiar with is https://github.com/keirf/greaseweazle. It allows you to graft something as simple, cheap, and readily available as a Blue Pill board to a 3.5", 5", or even 8" floppy drive to read and write media. Better yet, it has none of the sector and timing limitations of classic floppy controllers. The hardware works at the flux level and all the data format and sector encoding is done in software.