The way Bedrock Linux resolves potential conflicts between packages from
different distributions is by having multiple instances of such files. This
can mean multiple versions of any given executable will be present. When a
user runs a command, a specific rule set will decide which instance of an
executable is run if multiple are available. To bypass this rule set and
explicitly specify which is to be run one can use the
firefox is provided by multiple
strata (such as Arch and Fedora),
and the user would like to specify which is to run (rather than allowing
Bedrock Linux to chose the default), one can
brc, like so:
brc fedora firefox
If no command is given,
brc will attempt to use the user's current
If the value of
$SHELL is not provided by the
stratum it will fall back to
bri command will provide information about the
strata based on which
flag is used.
bri -c will print Config values for the specified
bri -e will populate the
/etc/bedrock_stratum file. This provides small
performance improvement for
bri -h will print the Help
bri -i will print a list of enabled
strata and aliases.
bri -I will print a list of all
strata and aliases, enabled and disabled.
bri -l will print List of enabled
bri -L will print List of all
strata, enabled and disabled
bri -m will prints Mount points in current
stratum OR following
bri -M will prints Missing mount points in current
stratum OR following
bri -n will print Name of
stratum corresponding to current process
bri -p will print the
stratum that provides the following Process id or (non-numeric) Process name
bri -P will print a list of Processes provided by the current
stratum OR following
bri -s will print the setup Status of the current OR following
bri -w will print the
stratum Which provides the command(s) in the argument(s)
brl command will run its argument in the
local context of all enabled
Attempt to ping bedrocklinux.org to check if networking/DNS is working
brl ping -c 1 google.com
Run 'apt-get update && apt-get dist-upgrade' with the
apt-get from all
strata that have apt-get available in the
brl -c 'brw apt-get|grep "(
direct)$"' sh -c 'apt-get update && apt-get dist-upgrade'
List all of the pids and their corresponding
strata. Can append
| sort -n to sort by pid.
brl bri -P | grep -v "brl\|bri"
/etc/passwd requires the full path to the user's desired shell. While this
is available through via
implicit access through
/bedrock/brpath/bin/, due to how the
implicit subsystem is
currently implemented any indication that the shell is a login shell is lost.
To resolve this, Bedrock Linux provides a meta-shell,
brsh, which simply
calls the shell configured in ~/.brsh.conf.
brw command is simply an alias to parts of
bri. Without any arguments,
brw will print the name of the current
bri -n). If arguments are
provided, it will indicate which
stratum provides the listed command(s) (
brp executable is responsible for maintaining the
directory and thus allowing
implicit file access. This is typically
launched during boot; end-users will rarely ever have to run it
is configured via /bedrock/etc/brp.conf.
brs can be used to enable and disable
strata. After enabling or
stratum, it will inform
brp to update its internal list of
To disable then reenable:
If config/frameworks have changed since a
stratum was enabled, and one
would like to add new mount items to a running
stratum without disabling
it, it is done like so:
brs update may miss things such as subshare items and new
components of a union item. Generally, a full
brs reenable is recommended
brs update if it is not a problem.
bru command will mount a filesystem, unioning the contents of two
directories. Specifically, it implements the required functionality for the
union stratum.conf setting. Like
is mostly managed by the system and it is unlikely the end-user will need to
run this directly.
brn command bootstraps other init systems. It reads
brn.conf and, through querying
enable values in the union stratum.conf
setting, optionally prompting the user to select a init to use, then hands off
control to that init.
bru this is mostly managed by the system and it is unlikely
the end-user will need to run this directly.
If you run into difficulties booting,
brn can be told to open a debug shell
before handing control off to the specified init by setting "debug_brn" on the
kernel line in the bootloader. Most bootloaders will let you edit the kernel
line for the given session in some manner, e.g. selecting it in a menu and
e. Consider placing this before "init=" to ensure the
kernel/initrd does not interpret this as an argument for the init command. To
resume booting the system after you have completed your debugging, exit the
debug shell - e.g. with
exit or ctrl-d.
This command gathers information about the Bedrock Linux system which may be
useful in debugging issues. When reporting an issue, strongly consider
including a link to the
brr output (from a paste website - there are many
freely available ones online, take your pick) with the report.
By default it prints to stdout. It can be made to log to a file with the
Depending on the specific issue you've run into, consider running
brr in the
following situations (and reporting the results):
init stratum, e.g.
brc init /bedrock/bin/brr and/or
brn debug shell. Consider using
/bedrock/brr-out in the debug shell then exiting the shell to continue the
boot. From the booted system, read
/bedrock/brr-out and make it available.
Depending on the severity of the issue, other more natural log locations such
/var/run/brr-out may not
work as expected.
init= in your bootloader's kernel boot line to
/bedrock/bin/brr -f /bedrock/brr-out. You may continue booting
exec /bedrock/sbin/brn or reboot with ctrl-alt-del. Then make the