|Feature||How well it works||Notes|
|cross-stratum applications||Minor Work-around||Clear cache to update application menu|
|cross-stratum dbus||Just Works|
|cross-stratum desktop environments||Major Issues||Requires hand-crafted, Bedrock-aware configuation.|
|cross-stratum dkms||Mostly Works||Sometimes must pair dkms and kernel|
|cross-stratum executables||Just Works|
|cross-stratum firmware||Mostly Works||Kernel will detect firmware across strata, initrd-building software needs investigation|
|cross-stratum info pages||Just Works|
|cross-stratum init configuration||Major issues||Requires hand-crafted, Bedrock-aware configuration.|
|cross-stratum libraries||Does Not Work||Theoretically possible but unsupported due to complexity/messiness concerns|
|cross-stratum login shells||Just Works||Specifying stratum requires special configuration|
|cross-stratum man pages||Just Works|
|cross-stratum themes||Mostly Works||Works work themes that support
|cross-stratum vt fonts||Does Not Work||Needs research|
|cross-stratum Wayland Fonts||Needs Testing||Needs research|
|cross-stratum Xorg fonts||Reports of inconsistency||Deeper investigation needed|
|ACLs||Mostly Works||Does not work in
|Any stratum's init||Mostly Works||Select init at init-selection menu during boot; see BSD style SysV notes|
|Any stratum's kernel||Mostly Works||Install kernel from
|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/octpoi||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 usage on Bedrock almost always works, with one
dkms needs to see two code bases to work:
Bedrock can make the former work across
stratum boundaries. A
stratum will automatically be able to pick up and use things like
nVidia or Virtualbox module code from other
Bedrock's ability to make the latter work across
strata depends on how the
kernel-providing distro sets up its kernel headers. Some distros place the
header source directly at
For example, Arch Linux does this. If such a distro provides your kernel,
dkms from non-kernel
strata can detect the kernel's headers.
Other distros make the kernel header source directory a symlink to a
location. For example, Debian symlinks them into
strata will be unable to follow such symlinks.
In practice, this means:
dkmsinstalled in the kernel stratum should just work.
stratumis a non-header-symlink distro.
In the scenario where
dkms does not detect headers
may manually run the kernel stratum's
strat to build and install
target-kernel-stratum dkms install
||kernel headers are
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.