Fedora IoT becomes an edition

The Fedora 33 release is currently scheduled for late October; as part of the process of designing this release, the deadline for system-wide change proposals was set for June 30. This release already has a substantial number of big changes in the works, so one might be forgiven for being surprised by a system-wide change proposal that appeared on August 4, which looks to be pre-approved. Not only that, but this proposal expands the small set of official Fedora "editions" by adding the relatively obscure Fedora Internet of Things Edition.

The Fedora distribution is released in a number of forms, including a fair number of "Fedora spins" that skew the distribution toward a specific use case. The flagship Fedora products, though, are the editions, of which there are currently only two: Fedora Workstation and Fedora Server. The former is obviously aimed at desktop deployments, while the latter is meant to be useful on back-end systems. This set of editions has been stable for some time.

There are a few "emerging editions" in the works, including Fedora CoreOS and Silverblue. Also on that list is Fedora IoT which is now poised to become the third edition to be part of the Fedora 33 release. The proposal notes that this is "largely a paperwork exercise at this point". While the remaining work may be confined to paperwork, the project may want to put some effort into documentation sooner or later; actual information about what Fedora IoT is and how to work with it is relatively hard to find.

Digging in

As one might expect, Fedora IoT is meant to be deployed on devices that make up the "Internet of Things". The vision statement behind Fedora IoT, as found in the associated "product requirement document", is:

The distribution is available for both the x86 and arm64 architectures. An attempt to run the Arm version on a Libre Computer "La Frite" single-board computer failed at boot time; that board is not on the list of supported platforms, so this outcome is arguably not surprising. The x86 version runs nicely enough in a virtual machine, though, so that is the version that your editor played around with.

Relative to its peers, the Fedora IoT edition is a small (but not tiny) distribution; installed, it requires a little under 3GB of disk space. It runs within 1GB of RAM with memory to spare — as long as one is not actually doing anything, anyway. The resource constraints of IoT systems force the set of installed packages to be relatively small; if one is expecting a GNOME desktop or a choice of relational database management systems out of the box, one will be disappointed. This is still Fedora, though, so those packages are readily available for installation later; Fedora IoT need not remain a small system.

Veteran Fedora administrators will have to adjust to a new way of managing those packages, though; one does not just run "dnf install" on a Fedora IoT system. Indeed, there is no dnf command available. This distribution, instead, is built using rpm-ostree; packages still show up in the traditional RPM format, but the way they are managed has changed considerably.

The rpm-ostree system is built around the concept of an immutable base image, perhaps augmented by one or more overlay images. The running system is never modified by package-management operations like installations or system upgrades. Instead, rpm-ostree maintains a set of parallel system images, two of them by default. The running image is immutable; any package-management operations will, instead, apply to the next image in the series (being simply the other image in a two-image setup). Thus, for example, the system administrator can install an essential package (Emacs, say), but that package will go into the alternative image and the action will not immediately yield a usable emacs command.

So, for example, the command to add Emacs is:

    # rpm-ostree install emacs

This command will fetch the required packages from the repository in the usual way and install them. Afterward, one can query the state of the system with:

    # rpm-ostree status
    State: idle
    Deployments:
      ostree://fedora-iot:fedora/stable/x86_64/iot
               Version: 32.20200817.0 (2020-08-17T15:28:05Z)
            BaseCommit: 4fa6233db3448c1ee5bb73b89fbddf54167108929d71248ece63ad6969ea308c
          GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0
                  Diff: 183 added
       LayeredPackages: emacs
    
    * ostree://fedora-iot:fedora/stable/x86_64/iot
               Version: 32.20200817.0 (2020-08-17T15:28:05Z)
                Commit: 4fa6233db3448c1ee5bb73b89fbddf54167108929d71248ece63ad6969ea308c
          GPGSignature: Valid signature by 97A1AE57C3A2372CCA3A4ABA6C13026D12C944D0

This output shows the two "deployments" (system images) managed by rpm-ostree; the one marked with the "*" is the currently running image. We see the other image with an additional package (emacs) layered onto it. Actually running that image (and, thus, being able to use Emacs) requires a reboot; at that point, the system will switch to the new image. The image that was running previously will remain in its current form in case a rollback is needed. Once the administrator starts making more changes, though, the previous image will be set up as a copy of the (new) running image, so changes like the addition of Emacs will be preserved going forward.

The idea behind all this mechanism is to make system updates safer. Since an update is applied to an idle image, it cannot break the running system even if it is interrupted at an especially inopportune time; this is good, since updates in general seem to be more than adequately endowed with inopportune times. The updated image will only be set up to run on the next boot after the update completes successfully. If, for some reason, the update as a whole proves to be inopportune, rolling back to the previous (and working) image is a trivial operation; the bootloader can be configured to do so automatically if appropriate. The result is, hopefully, an unbrickable system.

It is also relatively easy to implement a "factory reset" operation that simply removes any layered packages, stripping the system back to the original image. Naturally, rpm-ostree is able to check and enforce package signatures if the intent is to lock the system down.

Rolling releases, containers, and more

While Fedora can be a nice system to work with, administrators tend to reach for something else when the time comes to deploy a production system. One of the main reasons for that is Fedora's update cycle; any given Fedora release is supported for a year, after which the system must be updated to a newer release. That can be inconvenient on any production system; a similar requirement on a distribution for embedded devices could be a serious impediment to the project's "multi-million device deployment" ambitions.

To avoid this problem, Fedora IoT apparently opts out of the normal release cycle; instead, the project has committed to producing a rolling release with monthly updates. With rpm-ostree configured to pull down updates automatically, IoT systems can be kept up to date with little effort. If an update goes bad, the rollback mechanism is there to help users recover.

One other significant difference with Fedora IoT is a relatively strong focus on the use of containers to install applications. The podman tool is provided for this purpose; it's meant to look a lot like Docker, but without the need for any background daemons. Podman comes configured to pull images from docker.io by default. Your editor attempted to use it to install a few versions of NetHack that must all surely be legitimate, but none of them consented to run correctly — thus saving your editor a considerable amount of wasted time.

Beyond those changes, though, Fedora IoT feels much like any other Fedora system. The commands work in the same way, and the usual packages are available. This makes for a relatively rich and comfortable environment for embedded-systems work.

One can't help wonder about the ultimate objective, though. Fedora comes with no support guarantees, a fact that is sure to give pause to any companies thinking about which operating system to install in their million-device products. If Fedora is to have any chance of being deployed in such systems, some sort of commercial support option will have to materialize. When that happens, it may well go under the name of "Red Hat IoT" or some such. Fedora itself may not make it onto all of those devices, but Fedora users will have played with the technology first and helped to make it better.

---

to post comments