Bedrock Linux 0.7.20Bedrock Linux is one of the more interesting projects I have come across in my travels through the open source community. Bedrock Linux is a meta distribution, meaning it is not really a distribution of the Linux kernel and corresponding userland tools. Instead it is a special kind of tool which allows different Linux distributions to work together as though they were one operating system.
Put another way, consider that many people feel concern with how much diversity (or fragmentation, if you prefer) there is in the Linux ecosystem. People worry there are too many package managers, too many different formats and standards. They feel frustration at knowing different distributions have different strengths and weaknesses. They rankle at the conflict of wanting to install a Red Hat Enterprise Linux clone to get long-term stability while also wanting a few cutting edge programs from the Arch Linux repository.
Bedrock Linux seeks to reverse, or at least offer an alternative, to fragmentation. With Bedrock we can install one distribution, which we might think of as our main or primary operating system. Then, without using a virtual machine, Bedrock allows us to install a second distribution and effectively glue on the parts of the second distribution we want. This means you can have the stability and massive package repository of Debian in your main operating system while sampling the latest new packages being demonstrated in Fedora and grabbing rarely packaged programs from Arch Linux's User Repository (AUR). With Bedrock Linux the idea is that you don't need to choose which distribution you run and you don't need separate virtual machines or partitions for each distribution. Bedrock effectively glues multiple distributions, along with their tools and package managers, into one meta-distro.
Let's take a look at a hands-on example of Bedrock in action. Keep in mind, before diving in, that there are some limitations. There are components of distributions which don't play well when working across Bedrock's boundaries. There are also some limitations which are covered on the Bedrock website. For instance, it is typically a good idea to use the init software and desktop environments of your first (primary) distribution. In other words, you may run into trouble if you install MX Linux with SysV init and Xfce, but then decide you want to use the Cinnamon desktop and systemd from a secondary installation of Linux Mint later. Try to make sure the init, service manager, and desktop environments you want are all in the primary distribution. Add-on tools, package managers, and desktop applications from secondary systems all appear to work as expected.
The compatibility page points out that some specialized tools such as Timeshift for Btrfs snapshots and SELinux will not work correctly with Bedrock because it needs to do some unusual manipulation to glue various distributions together.
With these limitations in mind I decided to set up Void as my primary distribution and then perform three tests. The first was to install Arch Linux and try to add some software from Arch's user repository (also known as the AUR). The second was to install Ubuntu 18.04 and then replace it with Ubuntu 20.04 to see how Bedrock would do with fetching a new version of an operating system and then removing the older version, essentially performing a live upgrade without any reboots. I was also curious to see if Snap packages would work within Ubuntu running on Bedrock when Void is the primary operating system. Snap packages require systemd to work, which would be included within Ubuntu's level of Bedrock, but Void runs the runit init software which is not compatible with Snaps. I was interested in seeing the practical results.
I began my trial by performing a fresh installation of Void. I chose the distribution's glibc build with the Xfce desktop environment. Void is a relatively small distribution and was quick to set up. I then downloaded the appropriate Bedrock script for my CPU architecture (x86_64) and ran what Bedrock calls the "hijack" command as it converts an existing distribution into the Bedrock platform. The command looked like this: "sudo sh ./bedrock-linux-0.7.20-x86_64.sh --hijack".
Bedrock Linux 0.7.20 -- Bedrock hijacking the Void distribution (full image size: 196kB, resolution: 1280x1024 pixels)
The script produces a big banner with a warning letting us know this is a dangerous action and not reversible. After I accepted responsibility for the conversion attempt the script did some initial checks and completed its setup in under five seconds. The script concludes by advising us to reboot the computer to complete the Bedrock setup process.
From this point on, when the system booted it would pause and ask which init system it should run. At first I only had Void's runit installed and it was the single option available. If we don't make a selection the first one is picked automatically after 30 seconds.
At first Void seemed to be the same as always. I was able to login, run programs, and generally nothing appeared to change. However, I then remembered I had not installed software updates yet and ran the XBPS package manager to grab the latest package versions. Once I restarted the system Void could no longer boot. The start-up process would display a series of filesystem errors, all relating to Btrfs. I had set up Btrfs as Void's main filesystem with the thought of possibly using some of its features like volume expansion and snapshots later.
As I couldn't get the system to boot I performed a fresh installation, this time setting up Void on the ext4 filesystem. I then used the Bedrock script to hijack Void again. This time, when I used XBPS to install all waiting updates the system restarted normally. It seems Bedrock and Btrfs have some compatibility problems beyond the aforementioned Timeshift snapshot limitations.
At this point Bedrock is on the system, or put another way, Bedrock has become the underlying operating system. However, it isn't really doing anything for us yet. In my case, I was still (for all practical purposes) just running Void. To really make use of Bedrock we need to fetch new distributions (I call them secondary operating systems) and glue their parts onto Bedrock. We can do this with the "brl fetch" command. Each new distribution is referred to as a layer or "strata" by Bedrock. We can see available strata that Bedrock knows how to install by running "brl fetch --list". For example, to install Arch Linux on top of Bedrock we can run "brl fetch arch".
Bedrock Linux 0.7.20 -- Running the Arch package manager on a Void-based system (full image size: 194kB, resolution: 1280x1024 pixels)
Bedrock downloads and bootstraps a minimal set of Arch Linux packages and, from that point on, we can run Arch commands and use the distribution's pacman package manager. The Arch commands, such as pacman, act as though they are installed right alongside the Void tools. For example, if I run "xbps-install" it is recognized as a Void command, but if I run "pacman" it is automatically recognized as an Arch command and uses the Arch files and libraries to make it work. The experience is almost entirely transparent.
At this point I was able to install Arch's development packages and grab third-party packages from the Arch User Repository, build them, install them, and run these programs alongside Void applications.
Daily usage and surprises
Earlier I said that working with files and applications from the various levels (or strata) is nearly transparent. Typically running an application or performing a task on the command line acts as though Bedrock is just a typical Linux distribution and it pulls in the files and programs it needs from each strata seamlessly. However, there are times when this is not true and it can take a person by surprise.
For instance, I had the vi text editor installed on Void and the nano text editor installed under the Arch strata. If I wanted to edit a text file in my Documents folder, I could run either "nano ~/Documents/myfile.txt" or "vi ~/Documents/myfile.txt". Bedrock would correctly find the proper text editor, in its respective strata, and then open my file. This works wonderfully. However, there are times when each strata has its own copy of a file. For instance, the /etc/os-release file exists in both the Void and Arch distributions. If I ran "nano /etc/os-release" I would see the Arch version of this text file while if I ran "vi /etc/os-release" I'd get to see the Void version of the file. Bedrock would present to me the version of the text file corresponding to the strata in which it found the program I was running.
This can take a person by surprise if each distribution they install has its own copy of, for instance, the sudo configuration file. Depending on which tool we use to view the configuration file we can get to see an entirely different file. To work around this tricky situation Bedrock allows us to specify which strata we want to work with. This is done with the strat command, as in "strat arch cat /etc/os-release" or "strat void cat /etc/os-release". Both of these commands will display the contents of the release file in the named strata.
Bedrock Linux 0.7.20 -- Viewing files with the same name in different strata (full image size: 149kB, resolution: 1280x1024 pixels)
You might be wondering, as I did, if there is a way to determine which parts of the filesystem are duplicated across layers and which ones, like our home directory, are unique and therefore unaffected by using applications from different distributions. It looks as though running the mount command and checking for filesystems will show us if a region is duplicated across strata, requiring us to use the strat command to specify which layer we want to use. For instance, running "mount | grep /tmp" shows multiple /tmp directories are in use. Likewise "mount | grep /etc" shows more than one /etc directory. However, when I ran "mount | grep /home/jesse" there were no entries which seems to indicate my home directory is unique across all layers.
Applications I installed under my primary distribution (Void) would show up in the application menu, though programs installed in secondary levels (Arch and Ubuntu in my experiment) would not. I could work around this by either manually creating a shortcut in the application menu or copying the launcher I wanted from the secondary distribution's strata. For instance, I could copy launchers from the Ubuntu strata by running "cp /bedrock/strata/ubuntu/usr/share/applications/gimp.desktop ~/.local/share/applications/".
Adding more layers
Earlier I mentioned we can see which distributions can be installed on Bedrock as additional strata by running "brl fetch --list". However, if we want to grab a specific version of a distribution the syntax changes slightly. For instance, to see all available version of Ubuntu we can run "brl fetch ubuntu --releases". This will list the distribution's version using numbers or, in Ubuntu's case, with code names. We can then grab a past version of Ubuntu using a command such as "brl fetch -r bionic ubuntu" or "brl fetch -r focal ubuntu". In situations where we want to install multiple versions of the same distribution we need to make up a custom name of the strata (something other than just "Fedora" or "Ubuntu"). We can do this by specifying the "-n" flag, for example: "brl fetch -n myfocal -r focal ubuntu". This results in the new version of Ubuntu being called "myfocal" instead of the more generic "ubuntu" label.
Bedrock Linux 0.7.20 -- Running GIMP from the Ubuntu Bionic strata (full image size: 337kB, resolution: 1280x1024 pixels)
I tried to install Snap packages under the Ubuntu strata. The first snag I ran into was that the Snap software was not installed in the minimum Ubuntu layer. I installed snap and snapd. The snap client would run, but I could not get the snapd service to run. The service start command would bail out reporting it was unable to run in a chroot environment. I was, however, able to install the Flatpak framework, enable the Flathub repository and run games packaged with the Flatpak format.
Bedrock Linux 0.7.20 -- Running a Flatpak bundle (full image size: 148kB, resolution: 1280x1024 pixels)
Speaking of working with software packages, it is possible to install the same program under multiple strata. This is especially useful if we want to experiment with multiple versions of the same application. At one point I installed the GNU Image Manipulation Program (GIMP) 2.8 under Ubuntu Bionic and GIMP 2.10 under Ubuntu Focal. I could then launch either version by specifying the strata holding the GIMP version I wanted. From the command line this looked like "strat bionic gimp" and "strat focal gimp". The strata share one process space though and GIMP would only allow one version of itself to run at the same time.
Once we are done with a distribution we can remove it with the "brl remove" command. This wipes the distribution layer and its programs from the system.
More advanced concepts
Gluing multiple distributions together and using them almost seamlessly seems like enough complexity for me and I really like how well Bedrock handles merging distributions together. For people who want even more power, there are some additional interesting concepts Bedrock offers. For instance, we can make a copy of a strata. This means we could, for instance, make a backup of an existing distribution, perform an upgrade on it, and if anything goes wrong we could then simply delete the upgraded layer and go back to using the backup copy. In other words, we can make near-live images of our operating system before performing risky operations.
Bedrock is one of the more intriguing projects I have had the pleasure to use recently. It not only provides one heck of a toolbox for making distributions work together without requiring virtual machines or Docker, it does so quickly and with a minimal amount of knowledge required by the user. In short, we have a very easy way to run multiple distributions as if they were one operating system with almost no extra overhead in terms of CPU or memory usage. We do use a little extra disk space, but running Void, two versions of Ubuntu, and one copy of Arch only consumed around 7GB of disk space - about the same amount of disk consumption some large mainstream distributions use.
I also like how Bedrock essentially reverses distribution fragmentation. If you're tired of needing to run different distributions to gain access to a specific program or package manager, then you can run Bedrock and gain access to just about everything and use it seamlessly as one operating system. It's really quite a remarkable bit of engineering and, once I got used to how the different strata fit together, I encountered virtually no problems with it. There was the drawback that I couldn't use SELinux or Btrfs with Bedrock, but Bedrock's strata copying capabilities provide a sort of snapshot and there are other access controls people can use in place of SELinux. All in all, I'm quite happy with Bedrock.