06-05-2020, 06:57 AM
The pieces of Fedora Silverblue
<div><p>Fedora Silverblue provides a useful workstation build on an immutable operating system. In “<a href="https://fedoramagazine.org/what-is-silverblue/">What is Silverblue?</a>“, you learned about the benefits that an immutable OS provides. But what pieces go into making it? This article examines some of the technology that powers Silverblue.</p>
<p> <span id="more-31001"></span> </p>
<h2>The filesystem</h2>
<p>Fedora Workstation users may find the idea of an immutable OS to be the most brain-melting part of Silverblue. What does that mean? Find some answers by taking a look at the filesystem. </p>
<p>At first glance, the layout looks pretty much the same as a regular Fedora file system. It has some differences, like making <em>/home</em> a symbolic link to <em>/var/home</em>. And you can get more answers by looking at how libostree works. libostree treats the whole tree like it’s an object, checks it into a code repository, and checks out a copy for your machine to use.</p>
<h3>libostree</h3>
<p>The <a href="https://ostree.readthedocs.io/en/latest/">libostree project</a> supplies the goods for managing Silverblue’s file system. It is an upgrade system that the user can control using <a href="https://rpm-ostree.readthedocs.io/en/latest/manual/administrator-handbook/#administering-an-rpm-ostree-based-system">rpm-ostree commands</a>. </p>
<p>libostree knows nothing about packages—an upgrade means replacing one complete file system with another complete file system. libostree treats the file system tree as one atomic object (an unbreakable unit). In fact, the forerunner to Silverblue was named <a href="https://www.projectatomic.io/">Project Atomic</a>.</p>
<p>The libostree project provides a library and set of tools. It’s an upgrade system that carries out these tasks.</p>
<ol>
<li>Pull in a new file system</li>
<li>Store the new file system</li>
<li>Deploy the new file system</li>
</ol>
<h4>Pull in a new file system</h4>
<p>Pulling in a new file system means copying an object (the entire file system) from a remote source to its own store. If you’ve worked with virtual machine image files, you already understand the concept of a file system object that you can copy.</p>
<h4>Store the new file system</h4>
<p>The libostree store has some source code control qualities—it stores many file system objects, and checks one out to be used as the root file system. libostree’s store has two parts:</p>
<ul>
<li>a repository database at <em>/sysroot/ostree/repo/</em></li>
<li>file systems in <em>/sysroot/ostree/deploy/fedora/deploy/</em></li>
</ul>
<p>libostree keeps track of what’s been checked in using commit IDs. Each commit ID can be found in a directory name, nested deep inside <em>/sysroot</em> .A libostree commit ID is a long checksum, and looks similar to a git commit ID.</p>
<pre class="wp-block-preformatted">$ <strong>ls -d /sysroot/ostree/deploy/fedora/deploy/*/</strong>
/sysroot/ostree/deploy/fedora/deploy/c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4.0/</pre>
<p><em>rpm-ostree status</em> gives a little more information about that commit ID. The output is a little confusing; it can take a while to see this file system is Fedora 31.</p>
<pre class="wp-block-preformatted">$ <strong>rpm-ostree status</strong>
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/31/x86_64/silverblue Version: 31.1.9 (2019-10-23T21:44:48Z) Commit: c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4 GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4</pre>
<h4>Deploy the new filesystem</h4>
<p>libostree deploys a new file system by checking out the new object from its store. libostree doesn’t check out a file system by copying all the files—it uses hard links instead. If you look inside the commit ID directory, you see something that looks suspiciously like the root directory. That’s because it <em>is</em> the root directory. You can see these two directories are pointing to the same place by checking their inodes.</p>
<pre class="wp-block-preformatted">$ <strong>ls -di1 / /sysroot/ostree/deploy/fedora/deploy/*/</strong>
260102 /
260102 /sysroot/ostree/deploy/fedora/deploy/c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4.0/</pre>
<p>This is a fresh install, so there’s only one commit ID. After a system update, there will be two. If more copies of the file system are checked into libostree’s repo, more commit IDs appear here.</p>
<h4>Upgrade process</h4>
<p>Putting the pieces together, the update process looks like this:</p>
<ol>
<li>libostree checks out a copy of the file system object from the repository</li>
<li>DNF installs packages into the copy</li>
<li>libostree checks in the copy as a new object</li>
<li>libostree checks out the copy to become the new file system</li>
<li>You reboot to pick up the new system files</li>
</ol>
<p>In addition to more safety, there is more flexibility. You can do new things with libostree’s repo, like store a few different file systems and check out whichever one you feel like using. </p>
<h3>Silverblue’s root file system</h3>
<p>Fedora keeps its system files in all the usual Linux places, such as <em>/boot</em> for boot files, <em>/etc</em> for configuration files, and <em>/home</em> for user home directories. The root directory in Silverblue looks much like the root directory in traditional Fedora, but there are some differences.</p>
<ul>
<li>The filesystem has been checked out by libostree</li>
<li>Some directories are now symbolic links to new locations. For example, <em>/home</em> is a symbolic link to <em>/var/home</em></li>
<li><em>/usr</em> is a read-only directory</li>
<li>There’s a new directory named <em>/sysroot</em>. This is libostree’s new home</li>
</ul>
<h3>Juggling file systems</h3>
<p>You can store many file systems and switch between them. This is called <em>rebasing</em>, and it’s similar to git rebasing. In fact, upgrading Silverblue to the next Fedora version is not a big package install—it’s a pull from a remote repository and a rebase.</p>
<p>You could store three copies with three different desktops: one KDE, one GNOME, and one XFCE. Or three different OS versions: how about keeping the current version, the nightly build, and an old classic? Switching between them is a matter of rebasing to the appropriate file system object.</p>
<p>Rebasing is also how you upgrade from one Fedora release to the next. See “<a href="https://fedoramagazine.org/how-to-rebase-to-fedora-32-on-silverblue/">How to rebase to Fedora 32 on Silverblue</a>” for more information.</p>
<h2>Flatpak</h2>
<p>The <a href="https://github.com/flatpak/flatpak">Flatpak project</a> provides a way of installing applications like LibreOffice. Applications are pulled from remote repositories like <a href="https://flathub.org/">Flathub</a>. It’s a kind of package manager, although you won’t find the word <em>package</em> in the <a href="http://docs.flatpak.org/en/latest/index.html">docs</a>. Traditional Fedora variants like Fedora Workstation can also use Flatpak, but the sandboxed nature of flatpaks make it particularly good for Silverblue. This way you do not have to do the entire ostree update process every time you wish to install an application.</p>
<p>Flatpak is well-suited to desktop applications, but also works for command line applications. You can install the <a href="https://www.vim.org/">vim</a> editor with the command <em>flatpak install flathub org.vim.Vim</em> and run it with <em>flatpak run org.vim.Vim</em>.</p>
<h2>toolbox</h2>
<p>The <a href="https://github.com/containers/toolbox">toolbox project</a> provides a traditional operating system inside a container. The idea is that you can mess with the mutable OS inside your toolbox (the Fedora container) as much as you like, and leave the immutable OS outside your toolbox untouched. You pack as many toolboxes as you want on your system, so you can keep work separated. Behind the scenes, the executable <em>/usr/bin/toolbox</em> is a shell script that uses <a href="https://github.com/containers/libpod">podman</a>.</p>
<p>A fresh install does not include a default toolbox. The <em>toolbox create</em> command checks the OS version (by reading <em>/usr/lib/os-release</em>), looks for a matching version at the Fedora container registry, and downloads the container.</p>
<pre class="wp-block-preformatted">$ <strong>toolbox create</strong>
Image required to create toolbox container.
Download registry.fedoraproject.org/f31/fedora-toolbox:31 (500MB)? [y/N]: y
Created container: fedora-toolbox-31
Enter with: toolbox enter</pre>
<p>Hundreds of packages are installed inside the toolbox. The <em>dnf</em> command and the usual Fedora repos are set up, ready to install more. The <em>ostree</em> and <em>rpm-ostree</em> commands are not included – no immutable OS here.</p>
<p>Each user’s home directory is mounted on their toolbox, for storing content files outside the container.</p>
<h2>Put the pieces together</h2>
<p>Spend some time exploring Fedora Silverblue and it will become clear how these components fit together. Like other Fedora variants, all these of tools come from open source projects. You can get as up close and personal as you want, from reading their docs to contributing code. Or you can <a href="https://silverblue.fedoraproject.org/contribute">contribute to Silverblue</a> itself.</p>
<p>Join the Fedora Silverblue conversations on <a href="https://discussion.fedoraproject.org/c/desktop/silverblue">discussion.fedoraproject.org</a> or in <a href="https://webchat.freenode.net/#silverblue">#silverblue on Freenode IRC</a>.</p>
</div>
https://www.sickgaming.net/blog/2020/05/...ilverblue/
<div><p>Fedora Silverblue provides a useful workstation build on an immutable operating system. In “<a href="https://fedoramagazine.org/what-is-silverblue/">What is Silverblue?</a>“, you learned about the benefits that an immutable OS provides. But what pieces go into making it? This article examines some of the technology that powers Silverblue.</p>
<p> <span id="more-31001"></span> </p>
<h2>The filesystem</h2>
<p>Fedora Workstation users may find the idea of an immutable OS to be the most brain-melting part of Silverblue. What does that mean? Find some answers by taking a look at the filesystem. </p>
<p>At first glance, the layout looks pretty much the same as a regular Fedora file system. It has some differences, like making <em>/home</em> a symbolic link to <em>/var/home</em>. And you can get more answers by looking at how libostree works. libostree treats the whole tree like it’s an object, checks it into a code repository, and checks out a copy for your machine to use.</p>
<h3>libostree</h3>
<p>The <a href="https://ostree.readthedocs.io/en/latest/">libostree project</a> supplies the goods for managing Silverblue’s file system. It is an upgrade system that the user can control using <a href="https://rpm-ostree.readthedocs.io/en/latest/manual/administrator-handbook/#administering-an-rpm-ostree-based-system">rpm-ostree commands</a>. </p>
<p>libostree knows nothing about packages—an upgrade means replacing one complete file system with another complete file system. libostree treats the file system tree as one atomic object (an unbreakable unit). In fact, the forerunner to Silverblue was named <a href="https://www.projectatomic.io/">Project Atomic</a>.</p>
<p>The libostree project provides a library and set of tools. It’s an upgrade system that carries out these tasks.</p>
<ol>
<li>Pull in a new file system</li>
<li>Store the new file system</li>
<li>Deploy the new file system</li>
</ol>
<h4>Pull in a new file system</h4>
<p>Pulling in a new file system means copying an object (the entire file system) from a remote source to its own store. If you’ve worked with virtual machine image files, you already understand the concept of a file system object that you can copy.</p>
<h4>Store the new file system</h4>
<p>The libostree store has some source code control qualities—it stores many file system objects, and checks one out to be used as the root file system. libostree’s store has two parts:</p>
<ul>
<li>a repository database at <em>/sysroot/ostree/repo/</em></li>
<li>file systems in <em>/sysroot/ostree/deploy/fedora/deploy/</em></li>
</ul>
<p>libostree keeps track of what’s been checked in using commit IDs. Each commit ID can be found in a directory name, nested deep inside <em>/sysroot</em> .A libostree commit ID is a long checksum, and looks similar to a git commit ID.</p>
<pre class="wp-block-preformatted">$ <strong>ls -d /sysroot/ostree/deploy/fedora/deploy/*/</strong>
/sysroot/ostree/deploy/fedora/deploy/c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4.0/</pre>
<p><em>rpm-ostree status</em> gives a little more information about that commit ID. The output is a little confusing; it can take a while to see this file system is Fedora 31.</p>
<pre class="wp-block-preformatted">$ <strong>rpm-ostree status</strong>
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/31/x86_64/silverblue Version: 31.1.9 (2019-10-23T21:44:48Z) Commit: c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4 GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4</pre>
<h4>Deploy the new filesystem</h4>
<p>libostree deploys a new file system by checking out the new object from its store. libostree doesn’t check out a file system by copying all the files—it uses hard links instead. If you look inside the commit ID directory, you see something that looks suspiciously like the root directory. That’s because it <em>is</em> the root directory. You can see these two directories are pointing to the same place by checking their inodes.</p>
<pre class="wp-block-preformatted">$ <strong>ls -di1 / /sysroot/ostree/deploy/fedora/deploy/*/</strong>
260102 /
260102 /sysroot/ostree/deploy/fedora/deploy/c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4.0/</pre>
<p>This is a fresh install, so there’s only one commit ID. After a system update, there will be two. If more copies of the file system are checked into libostree’s repo, more commit IDs appear here.</p>
<h4>Upgrade process</h4>
<p>Putting the pieces together, the update process looks like this:</p>
<ol>
<li>libostree checks out a copy of the file system object from the repository</li>
<li>DNF installs packages into the copy</li>
<li>libostree checks in the copy as a new object</li>
<li>libostree checks out the copy to become the new file system</li>
<li>You reboot to pick up the new system files</li>
</ol>
<p>In addition to more safety, there is more flexibility. You can do new things with libostree’s repo, like store a few different file systems and check out whichever one you feel like using. </p>
<h3>Silverblue’s root file system</h3>
<p>Fedora keeps its system files in all the usual Linux places, such as <em>/boot</em> for boot files, <em>/etc</em> for configuration files, and <em>/home</em> for user home directories. The root directory in Silverblue looks much like the root directory in traditional Fedora, but there are some differences.</p>
<ul>
<li>The filesystem has been checked out by libostree</li>
<li>Some directories are now symbolic links to new locations. For example, <em>/home</em> is a symbolic link to <em>/var/home</em></li>
<li><em>/usr</em> is a read-only directory</li>
<li>There’s a new directory named <em>/sysroot</em>. This is libostree’s new home</li>
</ul>
<h3>Juggling file systems</h3>
<p>You can store many file systems and switch between them. This is called <em>rebasing</em>, and it’s similar to git rebasing. In fact, upgrading Silverblue to the next Fedora version is not a big package install—it’s a pull from a remote repository and a rebase.</p>
<p>You could store three copies with three different desktops: one KDE, one GNOME, and one XFCE. Or three different OS versions: how about keeping the current version, the nightly build, and an old classic? Switching between them is a matter of rebasing to the appropriate file system object.</p>
<p>Rebasing is also how you upgrade from one Fedora release to the next. See “<a href="https://fedoramagazine.org/how-to-rebase-to-fedora-32-on-silverblue/">How to rebase to Fedora 32 on Silverblue</a>” for more information.</p>
<h2>Flatpak</h2>
<p>The <a href="https://github.com/flatpak/flatpak">Flatpak project</a> provides a way of installing applications like LibreOffice. Applications are pulled from remote repositories like <a href="https://flathub.org/">Flathub</a>. It’s a kind of package manager, although you won’t find the word <em>package</em> in the <a href="http://docs.flatpak.org/en/latest/index.html">docs</a>. Traditional Fedora variants like Fedora Workstation can also use Flatpak, but the sandboxed nature of flatpaks make it particularly good for Silverblue. This way you do not have to do the entire ostree update process every time you wish to install an application.</p>
<p>Flatpak is well-suited to desktop applications, but also works for command line applications. You can install the <a href="https://www.vim.org/">vim</a> editor with the command <em>flatpak install flathub org.vim.Vim</em> and run it with <em>flatpak run org.vim.Vim</em>.</p>
<h2>toolbox</h2>
<p>The <a href="https://github.com/containers/toolbox">toolbox project</a> provides a traditional operating system inside a container. The idea is that you can mess with the mutable OS inside your toolbox (the Fedora container) as much as you like, and leave the immutable OS outside your toolbox untouched. You pack as many toolboxes as you want on your system, so you can keep work separated. Behind the scenes, the executable <em>/usr/bin/toolbox</em> is a shell script that uses <a href="https://github.com/containers/libpod">podman</a>.</p>
<p>A fresh install does not include a default toolbox. The <em>toolbox create</em> command checks the OS version (by reading <em>/usr/lib/os-release</em>), looks for a matching version at the Fedora container registry, and downloads the container.</p>
<pre class="wp-block-preformatted">$ <strong>toolbox create</strong>
Image required to create toolbox container.
Download registry.fedoraproject.org/f31/fedora-toolbox:31 (500MB)? [y/N]: y
Created container: fedora-toolbox-31
Enter with: toolbox enter</pre>
<p>Hundreds of packages are installed inside the toolbox. The <em>dnf</em> command and the usual Fedora repos are set up, ready to install more. The <em>ostree</em> and <em>rpm-ostree</em> commands are not included – no immutable OS here.</p>
<p>Each user’s home directory is mounted on their toolbox, for storing content files outside the container.</p>
<h2>Put the pieces together</h2>
<p>Spend some time exploring Fedora Silverblue and it will become clear how these components fit together. Like other Fedora variants, all these of tools come from open source projects. You can get as up close and personal as you want, from reading their docs to contributing code. Or you can <a href="https://silverblue.fedoraproject.org/contribute">contribute to Silverblue</a> itself.</p>
<p>Join the Fedora Silverblue conversations on <a href="https://discussion.fedoraproject.org/c/desktop/silverblue">discussion.fedoraproject.org</a> or in <a href="https://webchat.freenode.net/#silverblue">#silverblue on Freenode IRC</a>.</p>
</div>
https://www.sickgaming.net/blog/2020/05/...ilverblue/