__          __             __
\ \_________\ \____________\ \___
 \  _ \  _\ _  \  _\ __ \ __\   /
  \___/\__/\__/ \_\ \___/\__/\_\_\
                      Bedrock Linux

Introductory Material


Reference Material

Extending Bedrock


© Bedrock Linux 2012-2020
Linux® is a registered
trademark of Linus Torvalds

Bedrock Linux 0.7 Poki Feature Compatibility

Cross-Stratum Features

Features you can install in one stratum and use with programs from another.

If a given feature does not work cross-stratum, you may be able to get the desired effect by installing it redundantly in every corresponding stratum.

Category Feature How well it works Notes
Docs info pages Just Works
man pages Mostly Works mandoc man executable cannot read Gentoo man pages
Fonts vt Does Not Work Needs research
Wayland Needs Testing Needs research
Xorg Reports of inconsistency Deeper investigation needed
Misc applications Minor Work-around Clear cache to update application menu
dbus Just Works
desktop environments Major Issues Requires hand-crafted, Bedrock-aware configuation.
dkms Major issues Must manually pair dkms and kernel
executables Just Works
fcitx Mostly Works communication just-works, cross-stratum libraries don't; install fcitx in relevant strata
firmware Mostly Works Kernel will detect firmware across strata, initrd-building software needs investigation
init configuration Major issues Requires hand-crafted, Bedrock-aware configuration.
libraries Does Not Work Theoretically possible but unsupported due to complexity/messiness concerns
login shells Just Works Specifying stratum requires special configuration
Shell Completion bash Mostly Works Install bash-completion in all strata
fish Just Works
zsh Mostly Works Install zsh in all strata
Themes Cursor Does Not Work Needs research
Icon Just Works
GTK2 Minor Work-around export GTK2_RC_FILES, install theme engine
GTK3 Minor Work-around Set themes = /usr/share/themes under [cross-pass] in bedrock.conf
Qt Needs Testing Needs research

Any-Stratum Features

Features you can install from any stratum and use system-wide.

Feature How well it works Notes
bootloader Mostly Works install over other copies; never uninstall; GRUB+btrfs/zfs specific issue
init Mostly Works select init at init-selection menu during boot; BSD style SysV notes
kernel Minor Issue if non-bootloader stratum, manually update bootloader

Miscellaneous Feature Issues

Miscellaneous known feature-specific issues and limitations.

Feature How well it works Notes
ACLs Mostly Works Does not work in /etc
AppArmor, TOMOYO, SMACK Needs Testing Default profiles unlikely to work
BSD-style SysV init Major Issue Freezes on shutdown
build tools (e.g. make, configure scripts, etc) Minor Work-around Often confused without strat -r
grubs+btrfs/zfs Major Issue GRUB miss-updates grub.cfg on btrfs/zfs in Bedrock
nVidia proprietary drivers Manual Work-around Manually install drivers in relevant strata
pamac/octpoi Inconsistent Reports Inconsistent reports
ptrace (e.g. gdb, strace) Minor Work-around Install in same stratum as traced program, strat -r
SELinux Does Not Work Bedrock disabled on hijack
systemd-shim Major Issue logind access denied
timeshift Major Issue Confused by filesystem layout; do not use with Bedrock


Application Launchers

Many application launchers cache known applications and/or their icons. Some may fail to recognize new applications in /bedrock/cross/applications or icons in /bedrock/cross/icons.

Some such applications can be prompted to build the cache by removing ~/.cache and restarting the application menu provider (e.g. logging out and back in).

Application Launcher specific cache updating techniques:

Login shells

Linux systems typically store the full path to a login shell in /etc/passwd. Default login shell paths are local and will not be visible to another stratum's init system. Bedrock automatically changes any local login shell to a cross path in /bedrock/cross/bin/ to work around this concern.

If you would like to use a specific stratum's shell rather than the highest priority one, create a pin entry in cross-bin with the desired shell. After brl applying the new configuration, add the new pin path to /etc/shells and chsh to it.

Init configuration

Every stratum sees its own init configuration and only its own init configuration. By default, an init from one stratum will not know how to manage a service from another stratum's init.

It is possible to work around this by hand crafting init configuration. For example, one may make a runit run directory whose run file calls strat. For another example, one may make a systemd unit file whose Exec= line calls strat.

If you find hand creating init configuration is intimidating or bothersome, consider simply picking one stratum to provide your init and get all init-related services from that stratum.

Desktop Environments

Generally, getting:

all from the same stratum works as expected, and is the recommended workflow for most users.

The wiring between these components does not work automatically register across stratum boundaries. There are two components to this issue:

It is possible to make cross-stratum desktop environments work if the relevant init configuration is made by hand to launch all of the DE's dependencies. Whether /usr/share/xsessions changes are also needed depends on the specific init configuration strategy utilized. This may be difficult for some users and is not broadly recommended.


Bedrock supports cross-stratum dkms given the following constraints:

Bedrock does not enforce either of these constraints; the user must handle them manually.

The expected user workflow is to:

If package managers are not automating dkms, one may manually tell dkms to build and install a module:

strat -r target-kernel-stratum dkms install module/module-version -k target-kernel-version

BSD Style SysV

BSD-style SysV init systems, such as used by Slackware and CRUX, freeze on shutdown when run on Bedrock.

The leading theory is:

Quick and dirty tests show etcfs normally umounts on SIGTERM from root. It is not clear why this might not be happening during SysV shutdown. Bedrock's etcfs code does not do any direct signal handling. Debugging this may require digging into libfuse's code to see how it handles signals.


On MX Linux, the logged in user is expected to get certain permissions granted from systemd-logind, such as the ability to use the desktop environment's menu to reboot the system.

When running in Bedrock, this does not appear to work. This is likely due to MX Linux's use of SysV and systemd-logind via systemd-shim. The issue does not occur either on pure systemd systems nor on pure SysV systems.

Investigation found some process was reading local copies of what should have been global /etc files. This process was somehow reading /etc content under the etcfs mount. It is not clear what process was doing this, nor how it was doing so.

Manually writing through global /etc files to the init stratum (and consequently, systemd-logind's and systemd-shim's stratum) resolved the issue. However, automating this is not suitable as a general solution due to both performance and implementation complexity concerns.

Grub with BTRFS or ZFS

When GRUB updates grub.cfg on BTRFS it adds a subvol= field. Similarly, on ZFS it adds a ZFS= field.

GRUB's logic to populate these fields via grub-mkrelpath/grub2-mkrelpath appears to be confused under Bedrock and mis-populate the BTRFS and ZFS fields. This will cause boot failures.

Until this is resolved, it is strongly recommended not to use Bedrock, GRUB, and BTRFS/ZFS. Any two of the three is fine; consider another bootloader or filesystem.

Some quick digging into grub-mkrelpath's source found:

This is fine on most distros which only mount the root partition once. However, Bedrock's use of bind-mounts results in multiple /proc/self/mountinfo entries with the same major:minor number, which in turn means grub-mkrelpath may grab the wrong one.

Pamac and Octopi

Inconsistent reports have been provided for how well pamac and octopi work on Bedrock, both on Manjaro and Arch via AUR. Investigation may be needed.

Nvidia proprietary drivers

Most Linux graphics drivers have two components:

Most F/OSS Linux graphics drivers strive to make the two components forward and backward compatible such that their versions do not have to sync up perfectly. This allows a kernel from one stratum to work with an Xorg server from another stratum. However, the proprietary Nvidia drivers require these two components be in sync. Since the kernel module is shared across strata, this means every stratum that does anything with the graphics card requires the exact same version. Bedrock does not know how to enforce this itself. To work around this, one must manually install distro-agnostic portable proprietary Nvidia in all strata.

Download the proprietary Nvidia driver. Then run

where kernel-stratum is the stratum providing your kernel. This may require a linux-headers package be installed in the kernel-stratum. Note the -r: this is important to keep the Nvidia driver installer from "cleaning" graphics related files in other strata.

Next, run

for all remaining strata that require graphics drivers.

The bedrock stratum and other strata that do not utilize the graphics acceleration do not require the Nvidia drivers.

Man pages

Many Linux distros provide the man executable via one of the following:

For the most part, any of those three can read man pages from any distro. One may use Debian's man to read Void Linux's xbps-install man page and one may use Void Linux's man to read Debian's apt man page, for example, despite the fact that Debian uses man-db and Void uses mandoc.

There is one discovered exception: mandoc man executable, as provided by distros like Alpine Linux and Void Linux, cannot seem to read Gentoo's man pages.

Work arounds include:

GTK2 themes


GTK2 themes provide a gtkrc file. Export the GTK2_RC_FILES environment variable to a cross path for this file. For example, Arch Linux's materia-gtk-theme package provides a Materia-dark-compact theme whose gtkrc file is at


which is visible to all strata at


assuming arch is the stratum name. To make this one's GTK2 theme, export GTK2_RC_FILES to this location in one's environment setup (e.g. .bashrc):

export GTK2_RC_FILES="/bedrock/strata/arch/usr/share/themes/Materia-dark-compact/gtk-2.0/gtkrc"

GTK2 engines

GTK2 has a concept called "theme engines" which do not work cross-stratum. These must be installed in all corresponding strata. Running a GTK2 application without produce warnings such as

Gtk-WARNING **: 19:01:13.566: Unable to locate theme engine in module_path: "industrial",

These are trivially fixed by installing the corresponding engine package in the gtk2 application's stratum.


The GTK2 ecosystem does not appear to support $XDG_DATA_DIRS. It looks like NixOS explicitly patches support for $XDG_DATA_DIRS in, and gtk2 documentation mentions only using it for icon themes, not widget or cursor themes. Thus, we cannot simply point $XDG_DATA_DIRS to look into crossfs.

However, GTK2 appears to follow $GTK_DATA_PREFIX. It might be possible to point this to crossfs to make this feature just-work cross-stratum. More investigation is needed.


Most distros have hooks which will update bootloader configuration when a kernel is installed or updated. If the kernel and bootloader providing strata are the same, should work as expected. However, if they differ, the hook will not trigger upon kernel installation/update and the bootloader will not be automatically updated.

If you would like to get your kernel and bootloader from different strata, either create such a hook yourself or manually update the bootloader configuration when the kernel updates.