https://github.com/poettering/diskomator Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Resources + Learning Pathways + White papers, Ebooks, Webinars + Customer Stories + Partners * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing Search or jump to... Search code, repositories, users, issues, pull requests... Search [ ] Clear Search syntax tips Provide feedback We read every piece of feedback, and take your input very seriously. [ ] [ ] Include my email address so I can be contacted Cancel Submit feedback Saved searches Use saved searches to filter your results more quickly Name [ ] Query [ ] To see all available qualifiers, see our documentation. Cancel Create saved search Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert {{ message }} poettering / diskomator Public * Notifications * Fork 1 * Star 58 NVMe-TCP at your fingertips License LGPL-2.1 license 58 stars 1 fork Activity Star Notifications * Code * Issues 0 * Pull requests 0 * Actions * Projects 0 * Security * Insights More * Code * Issues * Pull requests * Actions * Projects * Security * Insights poettering/diskomator This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. main Switch branches/tags [ ] Branches Tags Could not load branches Nothing to show {{ refName }} default View all branches Could not load tags Nothing to show {{ refName }} default View all tags Name already in use A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch? Cancel Create 1 branch 0 tags Code * Local * Codespaces * Clone HTTPS GitHub CLI [https://github.com/p] Use Git or checkout with SVN using the web URL. [gh repo clone poette] Work fast with our official CLI. Learn more about the CLI. * Open with GitHub Desktop * Download ZIP Sign In Required Please sign in to use Codespaces. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching Xcode If nothing happens, download Xcode and try again. Launching Visual Studio Code Your codespace will open once ready. There was a problem preparing your codespace, please try again. Latest commit @poettering poettering Initial commit ... dc71d4b Nov 15, 2023 Initial commit dc71d4b Git stats * 1 commit Files Permalink Failed to load latest commit information. Type Name Latest commit message Commit time mkosi.extra/etc Initial commit November 15, 2023 15:07 systemd @ a3d3bf5 Initial commit November 15, 2023 15:07 .gitignore Initial commit November 15, 2023 15:07 .gitmodules Initial commit November 15, 2023 15:07 LICENSE Initial commit November 15, 2023 15:07 README.md Initial commit November 15, 2023 15:07 mkosi.build.chroot Initial commit November 15, 2023 15:07 mkosi.conf Initial commit November 15, 2023 15:07 mkosi.rootpw Initial commit November 15, 2023 15:07 View code Diskomator Why Even? Caveats Building Future README.md Diskomator NVMe-TCP at your fingertips Diskomator is an OS-in-an-EFI-binary whose only job is to expose all local disks as NVMe-TCP network block devices, as they appear. When built, it results in a single UEFI binary, that embeds a full OS root file system so that it does not need any further disk access while it runs. The EFI binary can be invoked directly from the UEFI firmware, for example by placing it an EFI System Partition (ESP). The OS root file system contains: 1. A Fedora Linux OS tree 2. A current version of systemd (v255-rc2), including systemd-storagetm and systemd-networkd. 3. An SSH server (just to make things easy to debug) 4. The Plymouth boot splash tool to make things pretty at boot and during runtime. The image is built via mkosi. All this then does is boot up into a minimal mode where systemd-storagetm and systemd-networkd are running. The former exposes all local block devices via NVMe-TCP, the latter configures all local network devices. The resulting EFI binary is relatively large (~300M), because it embeds all kinds of network drivers and graphics devices, plus their firmware. To keep things simply this stays close to upstream Fedora, without any attempts to minimize footprint. Why Even? My personal usecase for this goes something like this: I build immutable OS images for physical systems regularly and try them out. I could always write them to an USB stick on my development machine and then unplug it, and plug it into my testing machine. But that's cumbersome. My way out: just have a way how the test machine's disk can be written to directly from my development machine. And that's what Diskomator is. Other usecases: * Debugging * Remote installation of OSes * Turn your 2000 USD laptop into a very expensive USB stick * It's a fantastic show-case for UKIs, mkosi, Linux and systemd I think Caveats * [?][?] This currently does not enable NVME authentication nor encryption. If you boot from this your disk will be readable and writable to anyone with access to your local network! * [?][?] The root user is accessible via SSH with the password test, again to anyone with access to your local network! * [?][?] A debug shell is always available on Alt-F9. * This requires an EFI system, with a bit of RAM. After all the OS is entirely kept in memory. * The resulting EFI binary is not SecureBoot signed, you thus have to disable SecureBoot if you want to use this. (You can easily add that though, if you have a suitable key pair. mkosi will help with that, see documentation.) Building You'll need: 1. A build tree of a current systemd development version, to get the newest version of systemd-repart. Once distributions started to regularly ship v255, this manual step will go away. On a Fedora system you'd do it like this: sudo dnf builddep systemd git clone https://github.com/systemd/systemd.git cd systemd meson build ninja -C build And with that you should have a version of systemd built in the build sub-directory. No need to install this, BTW, just keep it around, we can use the build tree directly in step 4. 2. v19 of mkosi or newer. If your distribution doesn't have that yet, you can trivially check it out too: sudo dnf builddep mkosi git clone https://github.com/systemd/mkosi.git 3. A checkout of diskomator: git clone https://github.com/poettering/diskomator.git cd diskomator git submodule update --init 4. Now edit mkosi.conf in the diskomator directory locally on your system, and adjust the (by default commented) ExtraSearchPaths= line to point to the build tree from step 1. 5. You are now ready to build the image. In the diskomator git checkout run: sudo ../mkosi/bin/mkosi -T -i -f build (The -T -i -f you can theoretically drop BTW, I only specify them here since it improves rebuild times in case you hack on this.) Adjust the mkosi path to match where you placed the checkout tree from step 3. Once this completes you'll have two things in the mkosi.output/ subdirectory: diskomator.efi and diskomator.raw. The former is the EFI binary that we care about. The latter is a GPT disk image with an ESP with that very EFI binary in it (and no other partitions). The latter you can directly dd to an USB stick if you like, to boot another system from. You can even let mkosi do the dd'ing for you. Which is actually a good idea, since it will make sure the image is adapted to your chosen target device's sector and disk size : sudo ../mkosi/bin/mkosi burn /dev/disk/by-id/usb-SanDisk_Ultra_Fit_4C530000190505109123-0\:0 Replace the last argument in that command line by the path to the device node you want to write this to. As you can see I have a SanDisk USB stick I am testing this with. And that's really all. Once systemd v255 and mkosi v19 entered the various distributions step 1, 2 and 4 will become unnecessary (and the git submodule thing from step 3). Once that happened you only have to do 3 and 5. Future I'd like to live to see a future where people build appliances like this for various purposes, not just this specific NVMe one. For example, a nice thing to have would be an appliance whose only job is to make all local displays available via Miracast. I hope this repository is inspiration enough for an interested soul, to get this off the ground. Ideally, distributions would build images like this on their own. Specifically, I'd be delighted if Fedora (for example) would build an image like this and SecureBoot sign it, within their own build infrastructure and make that an offering to their users. In the meantime it might be nice to build diskomator on the usually available Open Source build infrastructure somewhere, so that people can just download a .raw or .efi file, instead of the cumbersome build steps listed above. Anyone interested in setting this up? Anyway, I hope this piqued your interest, now run and do with all this whatever you want! About NVMe-TCP at your fingertips Resources Readme License LGPL-2.1 license Activity Stars 58 stars Watchers 1 watching Forks 1 fork Report repository Releases No releases published Packages 0 No packages published Languages * Shell 100.0% Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time.