How FirstRib Booting Works; Overview

[wiak]

The following is as accurate as I could make it, but may have some errors, slight inaccuracies, including grammar issues. Please don't edit it in any way, however, since even a comma or semi-colon can make a big difference to ambiguity; I prefer to fix such matters myself to avoid loss of intended technical meaning. Thank you.

In two posts I want to explain in sufficiently correct detail the simple how and why FirstRib boot mechanisms work with most any distro filesystem, and not just specially contructed ones that are initrd dependent.
This first part, hopefully explains in its ten steps, why much of the confusion and claims regarding difference between full and frugal are simply a MYTH. The kernel doesn't care, and you can construct distros that freely mix technologies some claim are special to so-called 'frugal installs' (via, for example, an initrd, such as the FirstRib initrd, that has been carefully designed to always, best as I can, take into consideration the lack of correctness of various myths). These claims of filesystem 'difference' between some proponents of so-called 'frugal installation' tend, I feel, to obscure understanding how Linux works and the resulting lack of understanding tends to frighten away some perfectly capable users from becoming involved in some distro building and development. Distro development/building/creating is easier (and potentially much more flexible) than they end up believing, but not when they have been convinced that a frugal installed distro is a complicated different kind of Linux. It isn't.

Funnily enough, someone on this forum, for some clear reason, claimed that I was a distro 'builder' and not a 'developer', but the claim revealed a perhaps common lack of understanding of how systems are developed. At most, all of us involved in distro creation are distro builders - we develop these builds. The likes of Linus Torvalds, who design and develop core system code, such as the C sources internal to the kernel, have C code related extreme system-core technical knowledge that is not at all required for creating/building/developing new distros here on this forum, though any development work at any system level can be undertaken too - why not... However, usually, all we need to do build system development work is knowledge of how the overall system works in terms of bolting the various Torvald's-type designed components and subsystems together (for example aufs or overlay and so on ad infinitum). Much indeed like LEGO.

Like everyone else, who are the 'developers' on this forum, I know enough to actively assemble distros together and create a FirstRib build system that is less limited in terms of layers and filesystem types (compressed or uncompressed) than many an other design. I am indeed nothing more and nothing less than a distro builder (despite that in my past work life I was a system level C programmer developing TCP/IP protocols in the late 1980s early 1990s and an industry-based electronics engineer when involved in academic-led research), and thus like all other distro creators on this forum; I am not an artist, genius, or anyone special IMO; most anyone, at least in the richer developed countries, can go to university and learn whatever they want to and even then learn most of what they know by self-learning activities.

You could easily, I'm sure, become a distro creator too, or involved directly in that process, if you wished or had time for it, with but perhaps (if required) a little extra knowledge that dispels some of the popular myths often posted elsewhere.

PART 1:

1. A Linux system is stored as an organized filesystem whose arrangement can be thought of as having a hierarchy with the root directory '/' at the top.
   (Confusingly there is a directory actually called 'root', but that is something different; that is simply the home directory of user root).

2. The Linux filesystem unifies all otherwise separate parts of itself (such as partitions, physical devices such as hard drives and usb sticks) into that single directory structure with / at the top.

3. Most computers only really allow one program to run on them at any one time, but fast scheduling gives the useful illusion of many program process all running individually in parallel.

4. On boot, the computer uses a boot loader program, such as grub, to find the location of the linux kernel (in practice, now often named vmlinuz) and if used, an initial RAM filesystem, nowadays simply often named initrd.

5. The linux kernel then starts running and uses the initrd loaded into RAM that grub has located (via grub.cfg) for it. However in order to schedule start up any other part of the system, the kernel needs to have suitable driver programs that know how to read the storage devices (or it won't, for example, be able to load any programs from the externally stored main filesystem parts, which it needs to be able to 'mount' as part of the overall filesystem).

That boot-needed media-finding driver code is sometimes built into the kernel (a 'huge' style of kernel) or supplied as separate module driver programs (boot-media-related driver modules being then needed inside the initial-loaded initrd). If the kernel can't find the required driver/module/firmware code it will be unable to boot the Linux system so you will get a Kernel Panic (i.e. the system will freeze/crash). A kernel panic will also commonly result if the initial boot init cannot at the end of its work find the real root filesystem init that is most usually stored in main filesystem at location /sbin/init.

1. Assuming the kernel finds the required boot-time driver code, it then looks for the first program to run, which it expects at pathname /init or /linuxrc within the RAM-loaded initrd filesystem. It is important to understand that any program the computer system runs must first be loaded into RAM for its code to be executed (including the kernel itself).

2. A major job of that initial boot-time init is to unify all the physical hard drives and partitions and so on into a single directory structure. And this fact leads to something very important you should understand:

It DOES NOT matter whether that unified Linux single directory structure (overall Linux filesystem) was assembled as a full install or as a frugal install. By that stage, all the kernel cares about is that it can see all parts of the resulting filesystem.

THAT is why FirstRib initrd can boot pretty much any pre-built Linux distro root filesystem, be that provided as a "full install", or as a "frugal install" in the forum of multiple smaller filesystems (compressed or uncompressed) that the FR initrd program init needs to first glue together...

1. Once the required single directory structure is provided or assembled, the early init program (if used), typically does what is called a 'switch root' to where the top of the overall Linux filesystem is stored, and starts up the actual first process to replace itself as Linux Process ID number 0. Depending on the design, that PID0 process is usually begun with a program also called 'init' (but a different one to that earlier init; this second 'init' program can be stored anywhere on the overall Linux filesystem, but is typically held in directory /sbin). However people have designed different versions of that second main init program and given them different names, so it might be called 'init', or 'systemd', or 'runit', or some other name devised by someone else for helping the kernel to control the systems processes. The likes of sysV init, systemd, and runit, are referred to as 'init systems'; they all do pretty much the same job so doesn't 'really' matter which one you use (except that some work more efficiently overall than others if they are better designs...). My advice is: Ignore the hate, use whatever works best for you in practice; I tend to go with the flow (i.e. use whatever upstream distros recommend).

2. Nowadays, it is quite common for most all of the required single directory structure to be installed into a single partition. However, it was ALWAYS more traditional to store some parts of the required overall linux filesystem in separate filesystems, usually in the form of separate partitions, or could include filesystems stored in the form of a compressed files (one example being squashed filesystems, or in img files, or as network accessible drives/partitions/filesystems). Having the filesystem stored in pieces in that matter is nothing to do with whether the description full install or frugal install is being used - in either case, the component parts can be glued together via a process called 'mounting'. As long as the final result of the 'overall mounting process' results in a unified single directory structure the kernel can use. It matters not to the linux kernel whether we call the installation full or frugal. To a large extent, the distinction is a MYTH. It was typical, for example, in even the earliest UNIX, and also Linux, distributions that the directory /usr, for example was stored in read-only form on a separate disk partition, or even remotely on a different system.

In other words, Linux filesystem parts are typically stored on separate devices or in separate partitions or in compressed filesystems, for example, and part of the boot process includes fusing/joining/glue-ing all these parts together into a unified single directory structure (hierarchy with / at the top) that the kernel can use. It does not matter whether some sort of union filesystem is used for that assembly or not (e.g. some kind of union filesystem layer approach); once the structure is assembled the kernel couldn't care less how it was glued together - the concept of full install or frugal install is in that sense irrelevant.

1. In fact, in practice, a distro builder can use a mixture of so-called 'full install' techniques and frugal install techniques to glue the overall linux filesystem together (FirstRib initrd was indeed designed with that lack of difference between full and frugal install kept carefully in mind); i.e. can have different parts of the filesystem stored in separate partitions (in full install type parts) and simply use mountpoints and the mount command to join them into the system (in fact, ALL mechanisms, full or frugal, use 'mount' to include filesystem parts). Some of the filesystem parts can be stored on different devices (e.g. removable or network drives) or as compressed filesystems (e.g. squashed filesystem files or img files) and, again these can simply be mounted into the overall filesystem. And/or some only, or all, of these filesystem parts can be fused together via some union filesystem, merged like layers in a graphics image (using the likes of unionfs, aufs, overlay, or fuse) and the result of that merge then itself simply mounted onto the overall structure. May seem at first like magic, but in reality it is purlely logical and straightforward.

SUMMARY:

That is: FR initrd was carefully designed with that recognition of there effectively being no such thing as a full install or a frugal install, except that the latter term is used to indicate some form of layering is being employed; the kernel couldn't care less (traditional Linux filesystems commonly used read-only filesystem parts too, albeit usually in the form of separate partitions for separate parts of the filesystem); instead there are simply various techniques that can be used to store filesystem parts separately and then glue them together... Once assembled, you can then boot it. Hence, almost any distro can be booted by FR initrd, run exactly as normal, but be enhanced by the specially devised management of compressed or uncompresses layers capabilities (i.e. 'frugal install' capabilities) FR initrd can give them.

[wiak]

I've chosen to add to this first post "How it Works; Overview" to comment on various aspects of the FirstRib build system components and also, now and then, on the Kennel Linux addon material that adds much of the beef to the bones. A fact, apparently not known to many, is that the build system methodology and implementation is fundamentally extremely simple, which is why it requires little in the form of maintenance to ensure its longevity and usefulness.

You may well know by this time that FirstRib-based distro creations revolve around the flexible functionality provided by the FirstRib initrd. The build system simplicity is one result of that component, but also comes from the fact that most any (but not quite all) root filesystem can be booted using FR initrd.

Of course, a root filesystem is the guts of the operating system, and one is needed. Hence, FirstRib began life (in early 2019) with a single script (named build_firstrib_rootfs.sh) that can build a root filesystem from near scratch in whatever form the user/builder wants. The original of that script was written to optionally use the official package manager and repos of Void Linux (via the simple idea of starting only with busybox+package_manager), but the script was later given additional functions, one each, such that it could be used to build distros of other Linux flavours such as Arch Linux, Debian/Ubuntu/Devuan, and Fedora. One of the reasons I chose to begin FR with the ability to be fully Void Linux package management compatible is that, for one thing I really liked what Void Linux team had created, but also because a static compiled version of its xbps package manager was available so could be simply used with busybox to build the root filesystem from near-scratch. For Debian/Ubuntu/Devuan, build_firstrib_rootfs uses the traditional mechanism of first creating a not-so-small core base distro via debootstrap, and a simpler, but similar bootstrap approach was taken for Arch Linux and Fedora based builds.

However a key factor that has made KL/FR-based building simple and repeatable, and provide gradually user-developed build templates, is as follows:

To make it particularly flexible, the build_firstrib_rootfs.sh script was specially designed to first create a very basic core root filesystem and then call up a separate text file (f_ plug in file), which simply is a list of shell script commands to install and configure whatever apps and configurations and extras (like desktop backgrounds) the builder feels like adding in. The whole build design process is thus fundamentally easy and straightforward, and completely flexible, since the final build result is entirely decided by what the builder decides to add in via that simple f_plug-in, so can be any desktop environment (e.g. X or Wayland) or main init system (e.g. sysVinit, runit, systemd, or whatever) the builder wants to use. In KL/FR world, we thus don't generally argue (or need to argue) about the merits or otherwise of different environments or init system or overall system size and so on - these are choices entirely left up to the distro builder and no-one is forced to use anything...

1. build_firstrib_rootfs. So for many that produce Kennel Linux, firstrib-based distros, their design starts with the process of writing a new f_plugin (f_ name is optional, but helps to identify the file as a firstrib build plugin), which most of the time is really just extra shell commands for installing new apps using the core build_firstrib_rootfs provided package manager of whatever distro's repos are being used, along with other simple shell script commands to configure the system and perhaps download other wanted parts (such as desktop images) using the likes of wget from wherever they are being stored (can be from anywhere user/builder wants).

2. Bolt-on FR initrd to most any root filesystem. But, as I said, the core FirstRib initrd was designed to be usable with most any root filesystem; most any that exist out 'there'... So a second way to build a KL/FR-based distro is simply to extract or download a pre-existing Linux root filesystem from somewhere and pretty much just 'bolt the FR initrd' alongside that and include a suitable kernel/modules and firmware. The kernel can optionally be Puppy-style huge kernels provided in the form of: vmlinux and addon modules and firmware sfs files, but KL/FR distros can instead also use upstream kernels, which are not Puppy-type huge kernels usually so need some modules inserted into the FR initrd so it can find the underlying storage medium and boot the system. The bolt-on methodology is quite simple to do manually once you know how, but, once I knew how, partly to remind myself of the steps and commands involved an alternative build system was created named:

3. firstribit.sh, which is primarily used to automatically extract the existing root filesystem from most any pre-fetched live iso, such as those for MX Linux, Manjaro, Ubuntu, Linux Mint, and so on, with the end result being an FR initrd controlled frugal install of any of these mainstream or whatever distros, including save2flash save-on-demand capability and anything else you'd expect to find in most KL/FR-based distros.

4. Cloud-based FR rootfs builds: In January 2023 I published a Ubuntu-based KL/FR distro named KLU-jam (or more particularly an XFCE-based desktop version of that). I didn't use upstream debootstrap scripts to start this one off. Rather, I noticed that Ubuntu were producing at least as small as smallest debootstrap minimal systems for use in Cloud-installed scenarios. KLU-jam is thus the first Cloud-based KL/FR distro. That minimal cloud root filesystem, like those of debootstrap, is commandline-based only so Iike with a debootstrap build I still had the job of adding everything else to that to end up with a GUI desktop design. Though I did use a variation of build_firstrib_rootfs script to do that, I ran out of time putting all commands I used into script form and never got round to thus finishing or publishing the build script. However, I'm soon to produce a Ubuntu Noble Numbat variation, and after experimenting with some basic builds, I'm right now in the process of repeating my work in a new variation of the build_firstrib_rootfs script specially tailored for this Cloud image start situation. I toyed with the idea of adding this alternative cloud image build ability as a new function inside build_firstrib_rootfs, but decided the script was focussed on a more ground-up build type and should be left as that (despite debootstrap itself not exactly being 'ground-level' approach. Void Linux xbps + busybox certainly is...). Hence I will soon be announcing that alternative build_firstrib_rootfs_cloud variant, though for now at least it will be Ubuntu-cloud-image specific.

Whilst it remains easy enough to simply fetch a Ubuntu cloud image and manually 'bolt' FR initrd onto that and so on, the advantage to purposively creating a build_firstrib_rootfs_cloud script is that the f_plugin approach will work with this almost identically. The simplicity of that f_plugin approach has also proven to provide the build system with extremely flexible and repeatable power - each newly written f_plugin file turns out to act as a great template for others to start their own designs from - the very way it works removes the need to reinvent the wheel, as any and all KLV builders, for example, can testify; the f_plugin system effectively creates a collaborative approach as long as people publish the f_plugins they ended up with for their distro build

That old KLU-jam distro, thus acted as only an exemplar. I don't expect there will only be one KL Noble Numbat variant. Rather, a whole new KLU development area will become naturally available - new, but f_plugin familiar - such that anyone wanting to craft their own (and no single person will ever produce all that could be produced anyway) will find it easy to do so. Much of what has been learned particularly in KLV building (and certainly most all regarding KL utilities for save on demand, rollbacks, merging of fs layer components and so on) will be immediately familiar and usable in KLU cloud building. Perhaps other distro cloud variants will be identified and thus become another option too. Note that in KL world there is no fear of too many distro types or creations - most distro development work is in-common and less of a burden than some imagine and particularly not any great burden when f_plugin templates are consistently providing the collaborative incremental development approach. The power of initial simplicity is almost scary, but allows even this small forum team to produce continually being enhanced and polished variants, with in-common FR initrd and KL utilities provided in-common (near always available) familiarity and flexible powerful capability.

KL/FR-based distros thus end up as different to each other as their build creator wants them to be, but in terms of frugal install flexibility, system functionality, and powerful multi-instance facility they all share that in-common along with not only being modular and layer-based in design, but with layers that can each and every one be in either compressed sfs form or in uncompressed (normal directory) form, which has turned out to be uniquely useful in practice.

5. KL_single_build_script. To make publish builds even easier for non-developers, in Aug 2023 I created a very simply and straightforward frontend single script to not only run the likes of build_firstrib_rootfs.sh, but also to auto-fetch (via the likes of wget) all the needed frugal install parts, such as the kernel/modules/firmware, desktop backgrounds, layer addons and so on:

The original exemplar of that frontend assemble the parts script that I published was for distro named FRU_mini_jammy_wayland
viewtopic.php?p=96900#p96900

and shortly after, I published another almost identical frontend assemble script for a KLV xorg-minimal JWM mini:
viewtopic.php?p=97507#p97507

An additional purpose for these exemplars was to encourage anyone interested in trying to create and build their own KL/FR distro to read their contents because I felt that their simple recipe-like simplicity would help help them understand how to do it, and would also, I hoped, act as an exemplar and encouragement for other KL distro-makers here to also publish their own creations via same or similar frontend single script (as well as sometimes providing iso downloads or whatever).

viewtopic.php?p=98487&sid=ed478e0d971e1 ... 66c#p98487

------------------------------------------------------------
Initial (basic/core) build_cloud_firstrib_rootfs (for KLU Noble base creation, for example) coming soonish - I'm currently nearing completion of the initial draft of that (actually the script allows choice of oracular, noble, jammy, or focal). Completing the script becomes easier as it progresses, because once the f_plugin part works, really it is time to pass the build system over to those who are already familiar with everything thereafter anyway, though I do plan to provide a couple of simple (unpolished) f_plug exemplars with maybe one for the easy to implement XFCE and another with basic Wayland/Sway (which should be relatively small distro size for these modern times, though not minute; not that size matters most of the time...). These f_plugs will need further work, which I happily leave to others who have already demonstrated how good they are at such KL dev work to professional quality result and form.

Note that I'm also re-introducing the KL Lego-like series since starting with a core base component that I'm naming KLGO_Unoble (for this particular Ubuntu Noble core base system build) to emphasize the idea that GUI desktops and so on will be addon stages to that initial build.

[wiak]

So this new KLU project I'm working on is coming along nicely and I'm carefully taking my time writing the build scripts for it this time. Though that takes considerably longer, which is why I've ended up taking much longer to publish any part of it than I intended, the build script saves a lot of time in future maintenance and new versions. I actually mainly used scripts in building previous KLU_jam, but somehow lost most of that and didn't put on the cloud (I usually do, but must have been busy on other matters and forgot); net result is that a lot that would have been easy now takes a lot of time.

Overall though, I'm taking the time to streamline/organise building a little, but keeping backwards compatible such that build_firstrib_rootfs syntax remains the same and also in this special cloud image using version of that.

The other thing I'm taking time over is the single script frontend I used to pull down all the build parts and run that build_firstrib_rootfs main build script - a frontend approach that Sofiya has happily been using too; it makes building so much easier since I don't need to remember all the parts needed: the script does that for me. In practice, there will be multiple variants of that frontend, but at least in my own builds I'm standardising the first part of the name of that script to KLGO_make since potential KL/FR user/builders will just need to download that script and run it, and since it is simple in form, reading it provides instant easy to understand documentation of the whole build process - afterall, that is what a script often is: a recipe.

Anyway, last night I built one basic KLGO_Unoble_Swayland distro and one KLGO_UnobleXFCE distro from the newly written build scripts that keep the normal build_firstrib_rootfs and KL_single_build_script frontend syntax: using one f_plugin for each build, and all went well.

I remain very busy here on other matters so it is less my plan than used to be to release any particularly polished KLGO style distros, but nevertheless I'll likely spend another few days tidying these very basic builds up a little prior to releasing build scripts I've used to make them. Any iso releases will come later - and may not be released by myself anyway since final KL-team polished efforts are more likely to reach the stage where an iso release is worthwhile for a general audience. Overall I prefer scripted builds than iso releases for my own use anyway since the contents of iso tend to become old very quickly and especially when underlying distro is a rolling-release kind of distro. Of course I understand the attraction of simply dropping an iso into a Ventoy disk folder and no config required, but no doubt a KLGO_noble iso will appear sooner or later too.

Oh, other matter concerns what should be included in most all KL releases. In practice we do not try to control what goes into KL/FR produced distros, which are produced and polished by individuals who may or may not want to include facilities some users ask for. Nevertheless, we have been in the habit of releasing KL isos with an addon containing the likes of gtkdialog, filemnt and similar and, for my distro releases at least, I gradually hope to improve a version of that containing on the whole KL utilities found in KLV_Airedale that can then be used by anyone who also wants to include it as a layer. That's also why I prefer to keep as much as possible of these small KL utilities in /usr/local/ than under /usr/ alone since best overall to not mix them with upstream utilities. Unfortunately, there has been a longtime problem with the likes of save2flash calling snapmergepuppy in /usr/bin/. Trouble with just myself putting copies in /usr/local/bin has been maintenance - especially when such KL utils are generally stored in Void Linux xbps form and may themselves refer to other KL utilities in /usr/bin; best for portability I feel that the likes of save2flash assumes snapmergepuppy is in the executable PATH rather than to hard-code the path in the script itself.

It is good to be building something new again... so I'll get back to that now. I think this new KLGO_U is going to provide a lot of fun projects in its base release + whatever_addon form.
I'm not planning to include a browser in these base releases, but do plan to create an sfs browser addon that is invisible to the underlying apt/dpkg database, which can be downloaded as an extra if not simply using apt to install in more typical fashion. I'm purposively removing and and putting snap on hold since snap support is pretty heavy and I prefer native package management or the occasional AppImage when more convenient or necessary - of course anyone who wants to use snap packages can easily enough re-install and re-enable that if they so wish (just done in the f_plug file). Net result of this is that the base script will likely churn out a bit of a hybrid since my experiments including main Linux Mint repo in order to install their Chromium deb package worked very well for me in tests. So my own versions of this KLGO_U tend towards being Linux Mint underneath too... Up to the user to keep that 'Mint-capability' or not of course (just done in the f_plugin so can be included or left out).

NOTE that even when someone takes an already existing KL iso and remasters that with additions it would be best if they wrote a simple script that if run on the original of that distro would create the new variant - that method then acts also like a post-build plugin template rather than just releasing the remastered iso. To me that scripted way of updating an old iso is a perfectly acceptable, and in some ways better than the less accessible to some git approach - in terms of showing how things were done in step by step fashion. Any new plug file can additionally be stored on a git repo of course - the two approaches work fine together.

[wiak]

I actually 'completed' the new build from cloud image variant of normal build_firstrib_rootfs.sh (new special purpose cloud version is build_firstrib_rootfs_cloudimg.sh)

and also the single script build frontend (KLmake_cloudimg.sh)

They are working great in all tests so far.

The 'delay' in publishing is simply that I wanted to include 'test' exemplars including a better KL_utils addon than the one I made long time back.

Unfortunately, any f_plug takes a while and especially when it is ages since I wrote the Sway f_plug I published before and that was for upstream Void Linux KLV_Swayland and Ubuntu is a bit different (though only somewhat...). Let's face it, new f_plug files do take a while to write even when not aiming for high polish in this case... (that can come later). Alas I came busy in the 'garden' making drainage ditches and planning a mini-nature-reserve since some egrets been visiting and have several big tokay geckos around and even the odd monitor lizard and occasional visit from troop of monkeys... and it gets hot and my brain stops.

If I fail to publish with f_plugs I want to include within the week, I'll just publish main scripts for usage since several here know how to extend via f_plug anyway...