This page serves to describe plans for the then-upcoming release of Bedrock Linux 1.0beta2 "Nyla". Nyla has since been released on January 16th, 2016.
As of 1.0beta1 Hawky, Bedrock Linux utilizes its own, very limited, init. This was intended as a stop-gap solution until Bedrock Linux was able to utilize init from other distributions. 1.0beta2 Nyla should finally reach this goal.
The primary difficulty in doing this is a catch-22 situation: init systems
expect to be the first thing which is run; however, Bedrock Linux needs to run
client setup code before anything from a
client is run. For example, systemd
expects to be PID1. If another process is run first to setup the
forks off systemd, systemd cannot be PID1. If systemd is run directly without
setup, it will not utilize the
global system and either fail to
run properly due to missing
local dependencies or fail to see
files such as
The plan to solve this revolves around the fact that the
exec() system call
does not change PIDs. The parent process is replaced by the new code.
Thus, if the kernel/initrd calls a Bedrock Linux
/sbin/init, that can setup
clients and then
client's init (through
brc) such that the
client's init is still technically PID1.
Additional considerations must be made. For example, systemd attempts to
change the shared/slave/private attribute of
the root filesystem. When doing this, it assumes that the root directory
is a mount point. This is, typically, a very reasonable assumption. However,
the way Bedrock Linux works as of Hawky, this is not necessarily the case. In
order to handle this, Nyla will require some if not all
clients to have
local root directory be a mount point. This can be achieved quite
easily via a bind-mount; however, various Bedrock Linux utilities and
configuration formats must be adjusted to handle this change.
Another concern is that, while the
exec() plan will allow Bedrock Linux to
run code at boot in a way that does not interfere with a
client init, the
same technique may not be used to run code at shutdown.
Client inits may
not be able to properly umount mount points from other
Linux may need to hook into
client inits to run shutdown code. This may
brs disable on other
clients followed by a
to disable Bedrock Linux's
global system for the init
At the time of writing, a generic way to have run Bedrock Linux code when a
client init is shutting down is an open problem.
As of Bedrock Linux 1.0beta1 Hawky, a chunk of the system usually referred to
as "the core" or "bedrock-as-a-
client" serves multiple purposes in a way that
is not immediately clear to new users.
sh, in case other
clientsfail to do so.
The core shows up in commands such as
bri -l as "bedrock". This name does
not imply either of the services it provides. Moreover, it results in a bit of
a smurf-style filesystem. When installing Bedrock Linux, users will have a
/mnt/bedrock/bedrock/clients/bedrock path. The word "bedrock" loses meaning
in such situations. It also seems to encourage the idea that Bedrock Linux is
doing something similar to containers, as some of the system is
while some is, debatably, not; this results in a fair bit of confusion.
To remedy the above issues, bedrock-as-a-
client should be broken up into two
clients: "global" and "fallback".
The global client will only contain (1)
global files, (2) the
directory (which contains various Bedrock Linux subsystem related executables,
the clients, etc), (3) /boot, and (4) /sbin/init as is needed for this
should not have a
/bin/ directory in its root or anything
else that is typically
/sbin/init will call
/bedrock/bin/busybox to get its required executables. It will be technically
possible to run a shell with
global files as the
local files it via
brc global /bedrock/bin/busybox sh. The only processes that will be
typically run in the global
/sbin/init (and only for a short
time to bootstrap another
client's init) and
brp (as the filesystem it
makes should be
global). The global client will not have a client.conf
file - its access will be hardcoded into the various Bedrock Linux utilities.
Fallback will be technically optional but recommended. Fallback will contain a
/bin and other things which are typically expected to be available on a Linux
system, albeit a minimal version. It will provide a minimal init - effectively
what is being used as of Hawky as the init. It will use a client.conf like
client; it can be disabled or removed entirely.
Nyla will yet again attempt to include the
brg utility which was previous
planned for 1.0alpha4 Flopsie. This utility will be used to automate acquiring
clients. Ideally, a single command can be run which will automatically
acquire and setup all the files necessary for a
client from a desired Linux
distribution. This command could be used both during normal Bedrock Linux
usage as well as during installation (which could then be used to automate
acquiring a kernel during installation, for example).
Various tools exist to bootstrap Linux distributions; however, many of these
require distribution-specific code. For example,
debootstrap can be used to
bootstrap Debian-based systems; however, it requires
can be used to install a new RHEL-based system; however,
yum itself must be
available for this. This results in a catch-22 situation for Bedrock Linux
users: to acquire a
client, one must first have a similar
Various strategies are being pursued to bootstrap the bootstrap code in a portable manner, some of which are discussed here.
As of Hawky, when accessing a
local file, if the file exists:
directly, the process will see the instance of the file corresponding to its
explicitly, the process will see the instance of the file from the specified
implicitly, either the
directversion will be provided if it exists, or, failing that, the process will get the instance of the file from the highest-priority
clientthat can provide the file.
implicit access is handled is potentially problematic in that it
may seem inconsistent:
directversion will change depending on the calling process's
client. For example, if file is a pdf reader, and the user attempts to run the pdf reader from a
bashis provided by a gentoo
clientand gentoo provides the pdf reader, gentoo's pdf reader will start. However, if the pdf reader is automatically launched from a web browser, and the web browser if from an arch
client, and arch provides the pdf reader, arch's instance will start instead.
clientprovides a file, a user may become accustomed to expecting that file from that
client. If another higher-priority
clientgets the file, such as from a
apt-get dist-upgrade, which
clientprovides the discussed file will change.
While this is often acceptable (differences in versions of the
ls utility are
quite minor across distributions), there may be times when a user would prefer
the same version of a file be accessed consistently. To provide this
brp will be expanded to include the ability to create new
directories which will be placed at the very front of the
environmental variables. The files generated in these new directories will
thus always be the versions accessed via
Which files are pinned will be determined by:
rebootshould always be provided from the
clientthat provides the init process.
clientsbeing able to provide
startx, but the user would like a given
clientto always provide
startx, this can be configured via pinning.
Additionally, it may be possible to configure the given item to effectively
implicit access for a given item so it is always accessed
either from the same client or
explicitly or not at all, if this is