Features you can install in one stratum and use with programs from another.
If a given feature does not work
stratum, you may be able to get the desired effect by installing it redundantly in every corresponding
|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|
|desktop environments||Major Issues||Requires hand-crafted, Bedrock-aware configuation.|
|dkms||Major issues||Must manually pair dkms and kernel|
|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|
|Themes||Cursor||Does Not Work||Needs research|
|Qt||Needs Testing||Needs research|
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 known feature-specific issues and limitations.
|Feature||How well it works||Notes|
|ACLs||Mostly Works||Does not work in
|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
|grubs+btrfs/zfs||Major Issue||GRUB miss-updates
|nVidia proprietary drivers||Manual Work-around||Manually install drivers in relevant
|pamac/octopi||Inconsistent Reports||Inconsistent reports|
|ptrace (e.g. gdb, strace)||Minor Work-around||Install in same
|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|
Many application launchers cache known applications and/or their icons. Some
may fail to recognize new applications in
/bedrock/cross/applications or 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
Application Launcher specific cache updating techniques:
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
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
applying the new configuration, add the new pin path to
chsh to it.
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
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
For another example, one may make a systemd unit file whose
Exec= line calls
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
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:
/usr/share/xsessions/and only in that location. Unlike other resources, there does not appear to be a standard way to to extend the list of resource look-up locations. Consequently, there's no obvious way to add cross-stratum DE registration without risking upsetting a package manager.
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.
/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.
dkms given the following constraints:
dkmsexecutable should come from the kernel-providing stratum.
dkmsmodule version plays nicely with the kernel version.
Bedrock does not enforce either of these constraints; the user must handle them manually.
The expected user workflow is to:
dkmsmodules in providing
strata. Package managers may try to compile these for the kernel and error; that's okay, ignore the error.
dkmsin the kernel
stratum. When this
stratumupdates the kernel, it should detect cross-strata module source and compile accordingly.
If package managers are not automating
dkms, one may manually tell
build and install a module:
target-kernel-stratum dkms install
BSD-style SysV init systems, such as used by Slackware and CRUX, freeze on shutdown when run on Bedrock.
The leading theory is:
etcfscrashes instead of umounts. This makes all programs which read
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.
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
/etc files. This process was somehow reading
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) resolved the
issue. However, automating this is not suitable as a general solution due to
both performance and implementation complexity concerns.
When GRUB updates
grub.cfg on BTRFS it adds a
subvol= field. Similarly, on
ZFS it adds a
GRUB's logic to populate these fields via
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:
grub-mkrelpathgets the major:minor number of the root directory via
/proc/self/mountinfoto find a line with the same major:minor number.
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
grub-mkrelpath may grab the wrong one.
Inconsistent reports have been provided for how well
on Bedrock, both on Manjaro and Arch via AUR. Investigation may be
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
stratum. However, the proprietary Nvidia drivers require these two
components be in sync. Since the kernel module is shared across
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
Download the proprietary Nvidia driver. Then run
kernel-stratum is the
stratum providing your kernel. This may
linux-headers package be installed in the
-r: this is important to keep the Nvidia driver installer from "cleaning"
graphics related files in other
for all remaining
strata that require graphics drivers.
bedrock stratum and other strata that do not utilize the graphics
acceleration do not require the Nvidia drivers.
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
There is one discovered exception:
man executable, as provided by distros like Alpine Linux and Void Linux, cannot seem to read Gentoo's man pages.
Work arounds include:
strat gentoo manwhen you want to read a Gentoo man page.
mandocman executables and install at least one other
GTK2 themes provide a
gtkrc file. Export the
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
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.
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
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.