So there I am updating my new repository to enable using zfs in the ramboot images. This is a simplification and continuation of the previous work I did a few years ago, with some massive code cleanups. And sadly, no documentation yet. Will fix soon, but for now, I am trying to hit the major functionality points.
NyBLE is a linux environment for hypervisor hosts. It builds on the old open source SIOS work, and extends it in significant ways. Basically, we want to be able to PXE boot (or locally boot if you prefer, but managing OS or boot drives is something you never want to consider at scale) a full working OS into a ramdisk.
I have this working nicely for Debian 9, 8 and others, CentOS 7 (and RHEL 7 by extension). Eventually I’ll add others.
The purpose of NyBLE is to build what we want to use, not what the distro or image builder wants us to use. It is not a linux-from-scratch. It starts with a base distribution, so as to make questions about “but its X and we like Y, so why are you forcing us to change?” largely irrelevant.
OSes are, generally, a detail of an implementation. Distros are packagings of OSes in particular ways, that in theory, should impart some value to the users and consumers.
In the past, this may have been quite true. Currently, the only real values distros provide are centralized bug databases, security patches, and approximately working configurations.
Distros carry significant baggage. Ancient toolchains, often EOLed for years are being shipped with “modern” distros. Just remember they are more “stable”. Or something.
Distros often have unfortunate dependency radii. You can’t simply install package X, as it also depends on some functionality on Y and Z, which themselves depend upon … . Which means, building small footprint installations with all the functionality you need, say, ideal for memory booting, becomes fraught with peril of unmet dependencies.
While this is all … well … a fun challenge, think of it as fitting together puzzle pieces, where you only approximately know the shape of the pieces and the picture they display. And of course, each attempt iteration at fitting things together, could take minutes to hours …
… now add to this a temporal dimension. Suppose you want to compile support for a subsystem in the kernel. This support requires that the kernel-devel tree exist for a number of reasons. And suppose the kernel-devel tree is very large. Which makes PXE booting impossible.
So … now what you need to do is to temporarily load the tree, build and install the modules, and then remove the tree.
Sort of like cooking, where you need essence of kernel. But not the thing providing the essence as it would make the image too large.
This is the joy I am working through now. Works great BTW, in debian. Not so well in CentOS. Huge tree size.
The things we do to make end users lives easier and friction free …

2 thoughts on “NyBLE”

  1. OS? Oh, you mean that thing that runs containers and provides sanitized access to hardware?

    • Can and has run containers, and HVM. There are limits to isolation with what one can do entirely in software for sanitized access (firmware versions, cmos state, etc.).
      For containers, the world has largely settled on Docker-esque things, driven by a k8s framework. I like Singularity, and would like to see it adopted more.
      But, yeah, this is about providing a simple, repeatable base to run stuff on which is bit-level identical across all systems, starting from a known state. This makes the operational side of big systems (clouds, etc.) much saner.

Comments are closed.