Bedrock Linux stitches several distributions into one system

A distribution assembled from other distributions

Bedrock Linux is a Linux distribution composed of user-selected components from various other Linux distributions. The example the README gives is the installation process from one distribution, the init from another, a window manager from a third and a web browser from a fourth, with the goal that for day-to-day operations it is not readily evident that the various components were originally intended for disparate distributions.

That last clause is the hard part of the project. Any Linux distribution can be assembled from pieces; making the pieces behave as one system, with one shell, one package manager view and one set of configuration files, is what takes the engineering effort.

This particular repository is not the whole system. It contains all the userland code for a Bedrock Linux system, and it can create a script which may be used to install or update a Bedrock Linux system. In other words, the artifact it produces is the installer, not the installed system. The homepage is bedrocklinux.org, the licence is GPL-2.0, the primary language is C, and the last push was on 2026-04-13 with release tags for 0.7.31 in January 2026 and two earlier 0.7.31 beta tags.

Building the install script

The build is a make invocation, and the README is careful to list the dependency set first, because the list is long. It covers the standard UNIX utilities such as grep, sed and awk, autoconf, autopoint, bison, fakeroot, gcc 4.9.1 or newer, git 1.8 or newer, gpg as an optional item, gzip, libtool, make, meson 0.38 or newer, ninja-build, pkg-config, rsync, udev at build time only, and wget.

Internet access is required, because the build fetches upstream dependencies. After that, a signed script is produced with:

	make GPGID=<gpg-id-with-which-to-sign>

or an unsigned one with:

	make SKIPSIGN=true

The output is a file such as bedrock-linux-0.7-x86_64.sh, which is what you actually run on the target machine.

The build honours the usual make and C conventions, so -jN parallelises it and CFLAGS is passed through. One restriction is stated without room for interpretation: Bedrock's components must be statically compiled, the build system sets -static in various places, and you must not set -dynamic or otherwise try to change away from a static build. The Makefile also notes that the code base is compiled against musl through the musl-gcc wrapper, which in turn is why gcc is required.

Installing means replacing your root filesystem

The installation procedure is short enough to read in one pass, and each step has a consequence.

You install another, traditional Linux distribution first, and select a filesystem which supports extended filesystem attributes. You set up users and networking as you would typically do, then reboot into that fresh install. You get the bedrock-linux-<version>-<arch>.sh script onto the system, either by building it locally or getting a pre-built version from elsewhere, and you run it as root with the --hijack flag. You follow the prompts, and reboot, re-selecting the new install at the bootloader prompt.

At that point you are running Bedrock Linux, but with only the initial install's files. To get the rest, you fetch strata:

	$ brl fetch --list

lists the various distributions Bedrock knows how to fetch, and then, as root:

	$ sudo brl fetch arch debian

acquires the upstream distribution files. The README notes that if that fails you may need to look up the release and mirror information yourself and pass it with the --release and --mirror flags.

The word hijack in that step is not marketing. This is a root filesystem replacement, not a package you install and uninstall, and the extended attribute requirement is a real constraint on the filesystem you choose.

Strata are the unit of composition

A Bedrock Linux system is composed of strata, which the README describes as collections of interrelated files. These are often, but not always, one-to-one with other, traditional Linux distributions, and Bedrock integrates them together into a single, largely cohesive system.

To see what you have:

	$ brl list

lists the currently installed and enabled strata, while brl fetch --list shows the distros which can be easily acquired as strata.

The point of the model is that each stratum keeps its own coherent world. Once a stratum exists, commands from it can be run directly, and the README gives a sequence that makes sense on a Bedrock system:

	$ sudo brl fetch arch debian
	$ sudo pacman -S mupdf && sudo apt install texlive
	$ man pdflatex
	$ pdflatex preexisting-file.tex && mupdf preexisting-file.pdf

Arch's pacman installs mupdf and Debian's apt installs texlive in the same shell, and the tools then work together.

The integration is not limited to the command line. Graphical application menus and launchers automatically pick up applications across strata, and Xorg fonts installed from one stratum are picked up by an X11 graphical application from another stratum.

Which copy of a program you get

If there are multiple instances of an executable, Bedrock selects one by default in a given context, and if there are hints it can pick up on for which one to use, it is normally correct. brl which queries that decision:

	$ # arch, debian, and centos are installed.
	$ # running debian's init, and thus must use debian's reboot
	$ sudo brl which -b reboot
	debian
	$ # only arch provides pacman, so arch's pacman will be used
	$ brl which -b pacman
	arch

The resolution is context aware rather than a fixed priority list. The last example in the README makes that clear, since yum is a python script, so the python interpreter used to run yum also comes from centos:

	$ sudo yum update
	^Z
	$ brl which $(pidof python | cut -d' ' -f1)
	centos

To ask for a specific instance, strat selects one by name:

	$ # install vlc from arch
	$ sudo pacman -S vlc
	$ # install vlc from debian
	$ sudo strat debian apt install vlc
	$ # install vlc from ubuntu
	$ sudo strat ubuntu apt install vlc

The same command then runs a chosen copy, so strat arch vlc runs Arch's build and strat debian vlc runs Debian's.

Global files, per-stratum files, and the brl which output

File conflicts are the part any layer like this has to answer, and Bedrock's answer is a split between shared and per-stratum files.

To avoid conflicts, processes from one stratum may see its own stratum's instance of a given file. The README's example is that Debian's apt and Ubuntu's apt must both see their own instance of /etc/apt/sources.list. Other files must be shared across strata to ensure they work together, and all strata see the same file, with /home given as the example. Such shared files are referred to as global.

brl which reports the answer for a file in a context:

	$ # which stratum is my shell from?
	$ brl which --pid $$
	gentoo
	$ # that query is common enough the PID may be dropped
	$ brl which
	gentoo
	$ # which stratum provides ~/.vimrc
	$ brl which --filepath ~/.vimrc
	global
	$ # global indicates all stratum seem the same file; not specific to any
	$ # stratum.
	$ brl which --filepath /bin/bash
	gentoo
	$ brl which --bin pacman
	arch

To reach a specific non-global file, the path is prefixed with /bedrock/strata/<stratum>/, so brl which --filepath /bedrock/strata/debian/etc/apt/sources.list returns debian, and you can edit one stratum's file with another stratum's editor using strat ubuntu vi /bedrock/strata/debian/etc/apt/sources.list.

The repository layout and what hacking on it involves

The top level of the repository is small: .gitignore, LICENSE, Makefile, README.md, ReleaseNotes.md, detect_arch.sh, patches, releases, src, tools and watch-build-status.sh. The patches directory is where the differences between upstream distributions and what Bedrock needs are recorded, and src is where the userland code lives.

The Makefile documents a release path that goes beyond a normal build. To build for all supported architectures on a Bedrock Linux system, make release-build-environment is run as root to set up various build strata, and then make GPGID=<gpg-id-with-which-to-sign> release produces the release artifacts. The reasoning behind the design is stated plainly: the build system attempts to strike a balance between being overly dependent on the host system at the expense of portability, and maximizing portability at the expense of build time. Build tools such as gcc and meson are taken from the host system rather than recompiled, while upstream code which ends up within the output script is compiled from source.

Working on the code itself has its own tool set. The Hacking section asks for shellcheck, cppcheck, clang, gcc, tcc, scan-build, usually distributed with clang, and shfmt, to be installed so you can sanity check your work, for example before upstream changes to Bedrock Linux.

A concrete list of everything Bedrock can integrate, work-arounds for known limitations and other useful information is at bedrocklinux.org, and brl itself has much more functionality than the README shows, readable from brl --help.

Editorial conclusion

bedrocklinux-userland suits someone who wants to run, say, Arch's package manager next to Debian's init and a browser from a third distribution, since the strata model and the brl tooling handle the file conflicts that make that hard by hand. It is the wrong choice if you want a normal distribution with a stable package manager and a normal support story, because Bedrock is explicitly an experiment in integration and the project ships release candidates alongside stable versions. Before building, read the installation notes about the filesystem needing extended attribute support, and plan the install as a replacement for your root filesystem rather than something you can undo by deleting a package.

Frequently asked questions

Official sources

1. bedrocklinux/bedrocklinux-userland on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases