ハクソク

世界を動かす技術を、日本語で。

Floppinux – シングルフロッピー上の組み込みLinux、2025年版

112日前原文(krzysztofjankowski.com)

概要

  • FLOPPINUX は、シングルフロッピーLinuxディストリビューション作成のためのワークショップ
  • 2025年版 では最新カーネルや永続ストレージなど多くのアップデートを反映
  • 最小限のツールとハードウェアサポート を搭載し、誰でもカスタマイズ可能
  • BusyBox など軽量ツールの導入方法やクロスコンパイル手順を解説
  • 実機・エミュレータ両対応、安全なディスク作成方法も紹介

FLOPPINUX 2025年版：シングルフロッピーLinuxディストリビューション構築ワークショップ

  • FLOPPINUX は2021年にリリースされ、4年後も有用性が評価されたプロジェクト
  • 2025年版 では、最新のカーネルや永続ストレージ対応など、数多くのアップデートを実施
  • Linux From Scratch のフロッピー版とも言える、学習とカスタマイズに最適なワークショップ形式
  • 対象者 はLinuxの基本知識を有し、最小限の環境構築を体験したいユーザー
  • 最終成果物 は、フロッピードライブ搭載PCをLinuxターミナルとして起動・ファイル編集・スクリプト作成が可能なシンプルなディストリビューション
    • 264KB の空き領域をユーザーファイル用に確保

カーネルとツールチェーンの準備

  • Linuxカーネル6.14 （2025年3月リリース）がi486対応の最終バージョン
  • 作業環境は Omarchy Linux （Arch Linuxベースの64bit OS）を使用
    • POSIX互換システムなら手順は共通、必要パッケージのみ異なる
  • 作業用ディレクトリを作成し、全ファイルを管理
  • ビルドに必要なソフトウェア （gcc, make等）をインストール
  • エミュレータ は86BoxやBochsも利用可能だが、実機デバッグ以外では不要

カーネルの構築

  • linux/ ディレクトリにカーネルソース（6.14.11）を配置
  • 最小構成のカーネル設定 を作成し、必要最小限の機能のみ有効化
    • 不明なオプションは無効化しないことが推奨
  • 設定保存後、 arch/x86/boot/bzImage としてカーネルイメージが生成される
  • カーネルイメージをメインディレクトリに移動

BusyBoxの導入とクロスコンパイル

  • BusyBox 1.36.1 をbusybox.netまたはGitHubから取得
    • 軽量で多機能なUNIXツール群を提供
  • カーネル同様、 menuconfig で最小構成を選択
    • 必要なツールのみ選択し、容量を節約
  • 32bitターゲット のため、64bit環境ではクロスコンパイラを設定
  • ビルド後、 _install/ ディレクトリにベースファイルシステムが生成される
    • メインディレクトリへ移動・リネーム

追加ディレクトリ・設定ファイルの作成

  • Linuxシステムの最低限ディレクトリ構造 を作成
  • ウェルカムメッセージ や inittab、 rcスクリプト など、起動・動作に必要な設定ファイルを配置
  • スクリプトに実行権限を付与し、全ファイルの所有者をrootに設定
  • 圧縮アーカイブ 化し、作業ディレクトリに戻る

フロッピーディスクイメージの作成・書き込み

  • フロッピーサイズの空ファイル を作成し、フォーマット・ブート可能化
  • syslinux、カーネル、ファイルシステム をイメージにコピー
  • 実機やエミュレータでテストし、動作確認
  • floppinux.img が完成すれば、実際のフロッピーに書き込み可能
    • デバイス名を誤るとパーティション消去の危険性があるため要注意

注意事項・まとめ

  • デバイス名の指定ミス によるデータ消失リスク
  • GUIツールの利用や十分な確認を推奨
  • 本ワークショップを通じて、 シングルフロッピーLinuxディストリビューション の構築・カスタマイズが体験可能
  • FLOPPINUX - An Embedded Single Floppy Linux Distribution
    • By Krzysztof Krystian Jankowski
    • 2025.12

Hackerたちの意見

フロッピーディスクの音と、OSが読み込まれるまでのワクワク感、そしてそれが成功したときの喜びが懐かしいなぁ。

└

過去15年間に手に入れたほとんどのノートパソコンから聞こえるコイル鳴きは、少なくとも「コンピュータが動いてる」っていう懐かしい音を聞かせてくれる。コイル鳴きが設定できたらいいのにね :)

1.44MBのフロッピーディスクに入ってたQNXデモを覚えてる。すぐにフル機能のウィンドウマネージャーが立ち上がって、基本的なウェブブラウザもあったんだよね。それが1999年で、その後はそんなの見たことないな。

└

今のユニコードテーブルに収まるかな？

└

MenuetOS/KolibriOS: https://news.ycombinator.com/item?id=38059961 https://news.ycombinator.com/item?id=27249075 1999年のことだったけど、その後こんなの見たことなかったな。今はあるけどね ;-)

└

xwoaf-rebuildはそれに合致してるよ。 https://web.archive.org/web/20240901115514/https://pupngo.dk...

└

初めて見たとき、同じ気持ちになったよ。GUIやドライバー、あれらのものを1.44MBにどうやって収めたのか。

ここで説明されている永続性戦略（mount -t msdos -o rw /dev/fd0 /mnt）とホームへのバインドマウントの組み合わせは、スペースを節約するためのいいアイデアだね。ただ、物理的な磁気メディアのデータ整合性についてはどうなのか分からない。FAT12はジャーナリングファイルシステムじゃないし。現代のドライブでは、書き込み中にクラッシュすると、せいぜいイライラする程度だけど、33MHzのCPUを搭載した3.5インチフロッピーディスクでは、書き込み操作がかなりの時間ブロックされるからね。ユーザーが電源を切ったり、ヘッドが動いている最中にカーネルがパニックになると、そのディスクはおしまいだ。記事ではsyncについて触れてるけど、フロッピードライブでのsyncはすごく遅い操作で、ユーザーが中断する可能性もある。253KiBの空きスペース制約を考えると、フリースペースを生のブロックデバイスとして扱うか、遅いメディア向けに設計されたログ構造のファイルシステム（簡易版のJFFS2とか）を使った小さな追加パーティションにする方が良いかもしれないけど、それにはカーネルモジュールが多すぎるかも。誰か、raw FATファイルシステムをマウントする代わりに、initramfsイメージの最後にtarアーカイブを追加して永続性を持たせる実験をした人いる？シャットダウン時だけ書き込みを直列化する方が安全かもしれないし、もっと意見が聞きたいな。

└

ユーザーが電源を切ったり、ヘッドが動いている最中にカーネルがパニックになると、そのディスクはおしまいだ。納得、いい指摘だね。可能なら、書き込み用のディスクスペースにはセカンドドライブを使いたいな（今はフロッピードライブが2つあるのは珍しいって知ってるけどさ）。

└

ちょっと物議を醸す意見だけど、ジャーナリングは一般的に思われているほど有益じゃないと思う。何十年もFATを使ってるけど、データの破損にあったことはほとんどないよ。今ではPCよりも埋め込みデバイスの方がずっと多く使われてると思う。

└

ユーザーが電源スイッチを押したり、ヘッドが動いている間にカーネルがパニックを起こすと、そのディスクは消えちゃう。これは本当じゃない。スレッドの下の方でコメントしたけど、FATはバックアップテーブルを保持していて、それを使ってディスクを復元できるんだ。

└

昔の良き日々にはinitrdや他のRAMディスクのことなんてなかったよね。システム全体をディスクからそのまま読み込んでた。Slackware 8はその代表的な例だし、NetBSD（最新のやつでも）今でもデフォルトでそうやってるよ。

└

FATはドライバーからジャーナリングFSのように耐障害性を持たせることができるよ：1) 最初のFATに割り当てられたブロックをマークする。ここでクラッシュが起きたら、書き込まれたデータは不完全だから、FAT1をFAT2のデータで上書きして、すべての変更を破棄する。2) セクターにデータを書き込む。ここでクラッシュが起きたら、前と同じように古いファイルサイズを保つ。3) ディレクトリ内のファイルサイズを更新する。このステップは原子的で、一つのセクターを更新するだけ。ここでクラッシュが起きたら（ファイルサイズがFAT1と一致する場合）、FAT1をFAT2にコピーして新しいファイルサイズを保つ。4) 二つ目のFATに割り当てられたブロックをマークする。ここでクラッシュが起きたら、書き込みは完了しているから、空きスペースを計算して更新する。5) 空きスペースを更新する。

└

Turris OmniaみたいなデバイスでOpenWrtが、"root"パーティションにsquashfs（ROルートFSとしてマウント）を書き込んで、その直後に同じパーティションにjffs2（RWオーバーレイFSとしてマウント）を書き込むことができるんだ。だから、できるってことだね。

クリスマスに32ビット時代の使えるコンピュータを実際に作ろうとしたんだけど、結局問題はコンピュータの性能じゃないって気づいた。生産性のタスクには20年間十分な性能があったけど、ブラウザベースのソフトウェアを除いてね。私が直面した主な問題は、1) アプリケーションレイヤーでのソフトウェアサポート、2) ビデオドライバーのサポートだった。ディストリビューション向けにソフトウェアを構築するためのパッケージメンテナの努力はすごいけど、32ビット版のソフトウェアは何年も作られてないんだ。ソースからビルドすることは可能でも、使えるソフトウェアは非常に限られていて、CLIソフトウェアですら64ビットの依存関係で作られているものが多いからね。さらに、古いビデオカードドライバーはカーネルから削除されてる。これじゃ基本的なVGAの「セーフモード」レベルのサポートしかなくて、MPEG2を再生するのも難しい。最後の試みとしてDebian 5をインストールしようとしたけど、当時のライブCDはハイブリッドじゃなかったから、ISOをUSBからブートできなかった。焼く機材もなかったし、結局諦めちゃった。だから、こういうプロジェクトはコンセプト実証には楽しいけど、残念ながら古いコンピュータに命を吹き込むことはないと思う。

└

コンピュータは20年間、生産性のタスクに十分なパワーを持っている。 Office 97が今でも使えるのが不思議でたまらない。最近、VMで動かしてみたけど、記憶していた通りに動いて驚いた。もうすぐ30年になるのに、機能が詰まってるのがすごい。好みは人それぞれだけど、リボンより昔のOfficeのUIが好きだな。Wordにはたくさんのフォーマットオプションがあって、3D Word Artは懐かしさを感じさせるし、Excel 97は今でも非常に強力で、普段使う機能はほぼ全部サポートしてる。現代のハードウェアでは当然サクサク動くけど、1998年でもサクサクだったと思う。新しいバージョンの機能についてはみんなが挙げられるだろうけど、新しい機能が役立つと思うなら、あなたの体験を否定するつもりはない。ただ、ソフトウェアにどれだけクールなものが詰まっているかに驚いたんだ。

└

NetBSDがその古いハードウェアで動かすのに一番理にかなってると思う。逆に言えば、古いDOSゲームやアプリを動かすためのFreeDOSをインストールするのに最適なマシンを偶然作っちゃったかも。USBからインストールできるけど、BIOSが必要だから現代のPCハードウェアでは動かせないんだよね。

└

パッケージメンテナがディストロ用にソフトウェアをビルドするのにすごい努力をしているけど、32ビット版のソフトウェアは数年もビルドされていない。ソースからビルドすることは可能でも、使えるソフトウェアは非常に限られてる。CLIソフトウェアでも、64ビットの依存関係で作られているものが多いから、変だと思う？ Debian 12 Bullseye（oldstable）はi386ポートを完全にサポートしてるし、遅い32ビット時代のシステム（Pentium4/AthlonXP）でもそれなりに動くと思う。

└

2000年代初頭はLinuxをメインで使ってて、その頃は映画も見てたよ、DVDもね。もちろん、フォーマットはHDじゃなくてDivXやDVD ISOだったけど。Gentooを使ってて、mplayerのビルドフラグを最適化して動かしてたのを覚えてる。当時は500MHzのPentium IIIを使ってて、その後850MHzになった。mplayerの出力ドライバのパラメータを調整して、スムーズな再生を実現するのも大変だったけど、できたよ（mplayer -vo xvでXvideoサポート）。確か、Xを動かさずにフレームバッファ上でDVD .isoの再生もできた（mplayer -vo fb）。それに、"-framedrop"フラグも役立った（負荷がかかるときは25fps未満でも大丈夫だった）。それに、CPUにはSSE/SSE2のコンパイル時サポートが必要だね。ビデオデコードサポートのあるGPUを持ってたかどうかもわからない。

└

結局、問題はコンピュータの性能じゃないってことに気づいた。いや、これは現代の問題だね。JSの囚人たちがアサイラムを運営するとこうなる。クソみたいに膨れ上がったソフトウェアと、ゴミ開発者が作ったガレージアプリを動かす8300個のブラウザが同時に走ってる。LLMたちがそのクソみたいなデータで何をするのか、楽しみだね！

└

僕の32ビットのノートパソコンは2005年製のThinkpad T42で、CD-ROMもちゃんと動くし、Slackware15の32ビットインストールもまあまあできるから、これを試したことはないけどね。最初に思ったのは、今のコンピュータでqemuを動かして、LennyのISOをイメージとしてマウントして、qemuのハードドライブにインストールするのはどうかな？それから、そのハードドライブのイメージを32ビットのターゲットにddするって感じ。ターゲットマシンの起動方法によってはハードドライブキャディが必要になるかもしれないから、ちょっとハードウェアの後退ってことになるかもね。次に思ったのは、ターゲットマシンが最近のライブLinuxから起動できるなら、ネットワーク接続を前提に最小限のLennyをdebootstrapでインストールしてみるのもありかも（ターゲットマシンをネットワークに接続できるなら、Wi-Fiじゃなくてケーブルでつなぐ想定）。再起動して、必要なソフトウェアをインストールすればいいんじゃないかな。

└

2000年代にAMD 800MHz、256MBのRAMでCS1.6サーバーを立ててたことがあるんだ。最近、Mac Miniを買おうと思ってるんだけど、16GBじゃ足りないかなって考えてたら、そのサーバーのことを思い出した。あれはNATゲートウェイでもあったし、CSサーバー用のヒットスタッツがあるウェブサーバーもあったんだよね。それに、人気の16v16タイプのサーバーでもあった。どうなっちゃったんだろう？ いつの間にか16GBが最低ラインになって、32GBあれば悲しくならないってどういうこと？

└

デスクの下にP166があって、たまに何か動かそうとするんだけど、最大の障害はイーサネットポートがないことと、BIOSがUSBをサポートしてないことなんだ（ただ、USBポートが2つあるカードはあるけどね）。小さなLinuxディストリビューションはいくつか動かせたけど（これも試してみるつもり）、確かに、役に立つものは見つけられてないな。

└

OpenBSDとNetBSDはまだi386をサポートしてるみたいだね。ここでUSBスティック用のイメージが見つかるよ。基本システム（Xを含む）は大きな問題なく動くと思うけど（ハードウェアがサポートされていれば）、追加パッケージはちょっと運が必要かも。

└

Plop Boot Managerを試してみて！: https://www.plop.at/en/bootmanagers.html フロッピーディスクやCDドライブからブートできて、古いコンピュータでもライブUSBにチェーンロードできるんだ。俺は古いPentium MMXでフロッピーからCDをブートするのに使ったけど、めっちゃうまくいったよ（もちろん遅かったけどね）。

5分後に新しく焼いたフロッピーディスクができた。ああ、神様。

└

それはCD-R/RW時代に育った人の証拠だね。

このプロジェクトには本当に愛おしいものがあるよね。特に2025年5月の最後のカーネルを使ってるっていうのが。まるで誰かが最後の一度だけ愛情を込めて車を修理しているような感じがする。（疲れてるけど、もっと可愛いメタファーが見つかるかもね）

フロッピーをフォーマットする必要があるのかな。syslinuxやliloが生のフロッピーセクターから直接カーネルを読み込んで、initrdをそれに追加して、CONFIG_CMDLINE経由でカーネル内にコマンドラインを直接入れることができるのかな？u-bootならできるのは知ってるけど、8MB以上だし。代わりに、ext2はFATテーブルがない分小さいんじゃない？

最初に使ったLinuxディストリビューション、ダムスモールLinuxを思い出すな。これがゲームキューブにLinuxを移植する初めての試みだったと思うけど、メインのチームは結局Gentooに行っちゃったんだよね。メインページには「GNU/Linuxコミュニティのほとんどのプロジェクトと同じように、このプロジェクトも巨人の肩の上に立っている」と書いてある。私はCSの学位も持ってないただの一人の男だから、今のところこのプロジェクトはantiX 23 i386をベースにしてる。AntiXは素晴らしいディストリビューションで、元のDSLプロジェクトと同じ精神を持ってると思う。AntiXはMEPISと血統を共有していて、Debianの天才たちにも大きく依存してる。だから、このプロジェクトは巨人の肩の上に立ってるってわけ。つまり、DSL 2024は謙虚な小さなプロジェクトなんだ！ 2024年に700MBが小さいって言われるのはちょっとバカみたいだけど、2002年にDSLが50MBだったことを考えると、私は小さなアプリケーションを探すのにかなり苦労したし、700MBの制限内で動くデスクトップを作るためにいろいろ工夫しなきゃならなかった。サイズを減らすために、ISOは現在、ドイツ語、英語、フランス語、スペイン語、ポルトガル語、ブラジルポルトガル語のフル言語サポートを削除してる（de_DE, en_AU, en_GB, en_US, es_ES, fr_FR, es_ES, pt_PT, & pt_BR）。ソースコードや多くのマニュアルページ、ドキュメントも削除したよ。欠けてるファイルを復元するダウンロードスクリプトも提供してるけど、今のところうまくいってるみたい。 https://www.damnsmalllinux.org/

└

2、3週間前にPuppy Linux、DSL、TinyCoreLinuxを再確認して、VMでLLMエージェントをサンドボックスしようとしてたんだ。いい感じだよ。興味がある人には、Alpineがいろんなレビューを通して推奨されてたけど、そのアドバイスがどれだけ信頼できるかはわからない。

それで、まだこのハードウェアを持ってる人が20人くらいいるの？ その努力にはリスペクトするよ。

新しく作成したファイル用に264KBのスペースが残っています。これは、一般的な拡張フロッピーフォーマットを使用することでかなり増やすことができます。MSがWindows 95のフロッピーディストリビューションに使用した21セクター/トラックフォーマットは、ドライブによって広くサポートされていて（標準ディスクでも信頼性があると確認されて）、大量使用に安全だと考えられ、標準の18セクター配置が提供する1440KBの代わりに1680KBを提供しました。Linuxの標準フロッピーフォーマットツールは、そのようなレイアウトを作成することをサポートしています。 -------- [1] MSが拡張フロッピーフォーマットを発明したという提案もありましたが、彼らは時々「ウィンドウズフォーマット」と呼ばれていました。ただし、MSがWindowsやOfficeに使用する前から、他の場所でしばらく使われていたこともあります。[2] これはMS自身から出たものなのか、テックプレスが発明したのかはわかりません。[3] さらに拡張されたフォーマットもあり、OS/2インストール用フロッピーに使われた1720KByteのものもありました。