rc.conf configuration file covers the general system-wide configuration
options, especially boot configuration options. It is located at
. It is sourced as a bourne shell script, so be careful
with your syntax - there should be no spaces around the equals signs used for
establishing a setting. Change the text to the right of the equals sign to set
Sets timezone using the POSIX TZ environmental variable standard. For details on the nuances of the POSIX TZ environmental variable, see:
The content to put here can likely be found in /usr/share/zoneinfo/ in most
major distros. Find the file that corresponds to your timezone and look at
the very last line, for example with
tail -1 /usr/share/zoneinfo/path/to/timezone/file.
Sets whether the hardware clock is set to local time or UTC. Traditionally UNIX systems use UTC, but Windows uses local. If you are dual-booting with Windows, local may be preferable. Set to LOCAL or UTC accordingly.
Sets the language/locale information.
FSCK=1, Bedrock will attempt to run
fsck at boot. Otherwise, Bedrock
will skip running
fsck at boot. If you are using an initrd which runs
fsck, it could be beneficial to set
FSCK=0 to avoid running
fsck twice at
Sets the normal user POSIX PATH variable. These are the directories in which
programs look for executables. If you aren't sure what to put here, you almost
certainly want the value in the example below. Note that
should be sourced by your shell when it starts) will add items to the beginning
and end of this variable to make it play with Bedrock specific functionality.
Sets additional directories for the super user's (aka root's) POSIX PATH variable. Same general idea as above, but for the root user who probably needs access to the s* directories that the non-root user does not.
This is a list of directories used by the man executable to find man pages.
If you alter this from the default, be sure to also change
/bedrock/etc/brp.conf as well.
This is a list of directories used by the info executable to find info
documentation. If you alter this from the default, be sure to also change
/bedrock/etc/brp.conf as well.
This is a list of directories that contain directories used by the
freedesktop.org standard. For example, the items here could contain "icon"
directories which contain icons to be used by GUI programs. For another
example, it could contain an "applications" directory which contains .desktop
files that are used to populate application menus and mime/default programs.
If you alter this from the default, be sure to also change
/bedroock/etc/brp.conf as well.
The existence of a (root owned, non-root-unwritable) file at
indicates configuration for an (enabled)
client. If the filename is, instead,
client is considered disabled (so one cannot use it with
However, it will contain configuration necessary to re-enable it (with
The defaults are in general fairly good. To set the
client to use the default
configuration, simply include "framework = default" as the only content, like so:
echo "framework = default" > /bedrock/etc/clients.d/
If you would like to understand what these defaults are so you can change or improve upon them for your specific situation, continue reading the rest of this "client.conf" section.
The contents of the configuration files are simply a series of "key = value" lines. Blank lines and lines starting with "#" are ignored. Baring newlines, it is flexible about whitespace.
There are eight recognized keys in Bedrock Linux 1.0beta1 Hawky:
Bedrock Linux's files are broken up into two categories:
The difference between the two is there is only one instance of any given
global file, while there may be multiple instances (up to one per
client) of a
Without any configuration, everything is
local. There are three ways to make
global, one of which is "share". This is the most common method
and is the recommended default for most items. If neither the description of
"bind" or "union" seems fitting, this is the setting one should use to make
share = /proc, /sys, /dev, /home, /root, /lib/modules, /tmp, /var/tmp, /mnt, /media, /run
Bind is exactly like share except if any items are mounted in a "bind" item,
they are set to
local. For example, if one mounts a CD at /mnt/cdrom, and
/mnt or /mnt/cdrom is set to "bind", then only the
client which ran the mount
command will be able to see it. However, if the item is set to "share", then
any new mount points under it will be
global and processes from other
will be able to see the contents of /mnt/cdrom as well.
For the most part, you probably want share rather than bind. The main
exception is anything in /bedrock; as if anything there is set to "share"
explicit path will not function properly. Anything in
should be set to "bind". If you put
/bedrock/clients, or any specific
client, on its own filesystem, be sure to both (1) add it to
/etc/fstab to be
mounted at boot and (2) add a bind item for it to your
clients (or just to
the default framework).
bind = /bedrock, /bedrock/brpath, /bedrock/clients/bedrock
Both bind and share have one notable fault: one cannot call
rename() on them.
Typically, one shares or binds a directory which never gets
rename()'d and so
this is a non-issue. However, there is a notable exception with some files
/etc. Files such as
/etc/passwd should be
global, but neighboring files
/etc/issue should be
local. Thus, one cannot simply bind or share
/etc. Attempting to bind or share
/etc/passwd will cause problems when
the file is updated, as that file is updated via
The solution for this is the union setting. Union can be set on a directory
and told to only treat some files as
global and leave others as
is particularly important for
/etc. The downside to union is that it does
have some overhead; one would not want a performance-sensitive database, for
example, running on union. Thus, union should only be used where
an issue such that bind and share cannot be used.
Note that while one can typically break up one share or bind line into multiple ones without any trouble, union's syntax requires any collection of items within a union directory all be spelled out on the same potentially long line.
union = /etc: profile, hostname, hosts, passwd, passwd-, group, group-, shadow, shadow-, gshadow, gshadow-, sudoers, resolv.conf, machine-id
Bedrock Linux supports hooks to run programs just before or after a
enabled or disabled. Note that the programs are run in the core; if you
would like to run them in the
client that is being enabled or disabled, the
script itself must call
brc. Also note that the first argument to the
program will be the name of the
Bedrock Linux 1.0beta1 Hawky uses the "preenable" script to force certain
symlink setups on
Other possible uses for this being explored for future releases are:
Mount a sshfs or other remote filesystem on preenable and umount it on
postdisable so that a remote machine can be treated like a
client. This can
be advantageous over something such as
ssh -X in that all of the latency
will be on disk access, not user interface.
global files such as
client enable and disable so
that the UID and GIDs of the files on the
client and the rest of the Bedrock
Linux system are set proper if the
client is also being used as a stand-alone
system. This could be useful to dual-boot with a
client or have a
liveusb/livecd Bedrock Linux system which automatically detects and adds
local systems as
clients on boot.
preenable = /bedrock/share/brs/force-symlinks
clients will likely share similar if not identical settings. Instead
of duplicating many settings, a framework can be used to indicate that a
collection of settings stored in
is to be utilized. Frameworks have the exact same syntax as normal
client.conf files (and can refer to each other). Typical Bedrock Linux
systems may have one or two frameworks which which most
A reference framework with recommended defaults for most
clients should be
available by default at
framework = default
framework = default
share = /proc, /sys, /dev, /home, /root, /lib/modules, /tmp, /var/tmp, /mnt share = /media, /run bind = /bedrock, /bedrock/brpath, /bedrock/clients/bedrock union = /etc: profile, hostname, hosts, passwd, group, shadow, sudoers, resolv.conf, machine-id preenable = /bedrock/share/brs/force-symlinks
By default, Bedrock Linux uses mdev rather than udev. A number of
applications, such as xorg and SDL2 programs, assume udev is available and mdev
alone may not be sufficient for your purposes. If you would like to use udev
instead, ensure you have udev in a
client, and then follow the instructions
You must modify two files. The location of these files can differ a bit depending on if you are booted into another system installing Bedrock Linux or if you are in a running Bedrock Linux system.
If you are in another system with the Bedrock Linux filesystem at
/mnt/bedrock, the files are located at
If you are in a Bedrock Linux system, modify these files:
Once you have found the files, modify them accordingly:
rcS.udevso that the
UDEV_CLIENTvariable indicates which
sh /etc/init.d/rcS.udev(verbatim, do not change to compensate for where the system is currently mounted) to
The next time you reboot, udev should replace mdev.
To replace mdev with udev in the current session without rebooting, simply run
For the most part, this is a
/etc/fstab file such as you would find in any
other Linux distribution, and documentation for those distributions should
apply here as well. This file is primarily used for mounting partitions at
boot or setting up the functionality for devices to be easily mounted by an
end-user, such as optical drives.
However, there are a few additional things to note:
Bedrock Linux ensures
the root directory are all set up during the init process and do not
necessarily need to be placed here.
In order for the core Bedrock Linux to be treated as a
client, it needs to be
bind-mounted into /bedrock/
clients. This is done by default in fstab with
/ /bedrock/clients/bedrock bind defaults,bind 0 0
To use the Bedrock Linux meta-shell
brsh, create a file in your home directory
.brsh.conf which contains the contents that should be in your
environment. For example, if you would like to use
To have a
client daemon start or stop at boot/shutdown, place the relevant
command to do this in
respectively. If you are configuring this from installation where Bedrock
Linux's filesystem is mounted somewhere, prepend the mount point (such as
/mnt/bedrock to the path). If you are configuring this from a running
Bedrock Linux system, be sure to access the files in the core, in
Be sure that the items fork off into the background if they are long-running,
such as daemons. Consider appending
For example, to start Debian squeeze's
cups daemon at boot, place
the following in your
brc squeeze /etc/init.d/cups start
And, to ensure it properly closes at shutdown, place the following in your
brc squeeze /etc/init.d/cups stop
If you would like start/stop daemons during it which were written for systemd,
you may have to manually parse the unit files looking for
Exec= lines to
figure out what to place here, as managing systemd daemons are not yet directly
supported in Bedrock Linux. However, so long as the daemon is not functionally
dependent on systemd to run, it should be possible to figure out what systemd
is doing to manage the daemon and do so yourself.
The file at
/bedrock/etc/brp.conf is responsible for managing the filesystem
/bedrock/brpath filesystem. This filesystem is used to make files from
clients accessible, altering them as necessary so things "just work". If
client provides a file, this file could be made accessilbe through the
/bedrock/brpath filesystem for the other
For all of the headings in the config except
client-order, any keys will show
up on the root of the brp filesystem and will union all of the values for all
clients. For example, the line
/rootfs = /
means that if one looks at /bedrock/brpath/rootfs one will see a union of all
of the root directories of all of the
Items in the "pass" heading are passed through unmodified. Items in the
"brc-wrap" heading are wrapped in a script to call brc to change the
context; brc-wrap items should typically be directories containing executables.
Finally, "exec-filter" items are passed through unmodified except for "Exec="
and "TryExec=" lines which are modified to handle
local context issues.
clients can provide the same file, the one which provides the file
is the highest priority one of the group. To set the priority, add
the order you would like, one per line, under the "client-order" heading.
[pass] /rootfs = / /man = /usr/local/share/man, /usr/share/man /info = /usr/local/share/info, /usr/share/info /icons = /usr/local/share/icons, /usr/share/icons [brc-wrap] /bin = /usr/local/bin, /usr/bin, /bin /sbin = /usr/local/sbin, /usr/sbin, /sbin [exec-filter] /applications = /usr/local/share/applications, /usr/share/applications [client-order] centos debian arch
The brp filesystem's current understanding of the configuration can be read back by reading the file at
as root. If you change the configuration file at runtime and would like brp to reparse its config, write anything to that file as root
echo 1 > /bedrock/brpath/reparse_config
brs will automatically tell brp to reparse its config whenever a
enabled or disabled.
As a side note, this will not work as you may expect:
sudo echo 1 > /bedrock/brpath/reparse_config
That tells the shell, running as a normal user, to write the output of what
sudo echo says. If you would like to use
sudo for something like this, you
will need to use another program, such as
tee, to do the actual writing, like
echo 1 | sudo tee /bedrock/brpath/reparse_config