__          __             __
\ \_________\ \____________\ \___
 \  _ \  _\ _  \  _\ __ \ __\   /
  \___/\__/\__/ \_\ \___/\__/\_\_\
                      Bedrock Linux

Bedrock Linux 1.0beta2 Nyla

© Bedrock Linux 2012-2024
Linux® is a registered
trademark of Linus Torvalds

Bedrock Linux 1.0beta2 Nyla Tips, Tricks and Troubleshooting

This page contains tips, tricks and troubleshooting advice for various software and strata for Bedrock Linux 1.0beta2 Nyla.


Stratum Aliases

Rather than typing brc stratum, one can shave some keystrokes by generating aliases for all of the strata, like so:

for STRATUM in $(bri -l)
    alias $STRATUM="brc $STRATUM"
    alias s$STRATUM="sudo brc $STRATUM"

Consider placing that loop, or something similar, in your shell's rc file.

General issues

Proprietary Nvidia Drivers

The official Nvidia proprietary drivers works well in Bedrock Linux if set up properly.

The proprietary nvidia drivers are functionally two components: the userland component and the kernel module. The goal is to get the kernel module in /lib/modules so it can be utilized by the rest of the system and to get the userland component into (1) the stratum that provides xorg and (2) other strata which you would like to have graphics acceleration. Finally, note that mixing Nvidia driver version probably isn't a good idea; it may be best to stick with a single version everywhere.

While many distros do provide proprietary Nvidia drivers in their repos, different strata will most likely have different versions of the driver. Since uniformity is desired here, use the official Nvidia Linux drivers from the Nvidia website instead. Download the appropriate release of the Nvidia Linux drivers from here. Keep it somewhere that will continue across reboots, as you may reboot soon.

Nvidia's proprietary drivers do not play nicely with the nouveau drivers, and so the nouveau drivers must be disabled. Create or append to the file at /etc/modprobe.d/blacklist the following:

blacklist nouveau

If nouveau is currently loaded, it will have to be removed. If you have difficulty rmmod'ing it because it is in use, reboot. If it appears your initrd is loading it, add "rdblacklist=nouveau" to your bootloader's kernel line.

The driver installer may pick up components such as make across strata and end up attempting to install into the wrong location. To avoid this possibility, restrict the $PATH:

Next, install the proprietary driver module. In the stratum that provides the kernel (so the versions match), install the proprietary nvidia driver module by doing one of the following:

Finally, install the userland component in all of the strata which you would like to have acceleration in xorg. For each of these strata run the Nvidia proprietary driver installer with the --no-kernel-module option (since you already installed the kernel module) and the --no-check-for-alternate-installs option (to avoid blowing away nvidia driver installs in other strata). If you have a 32-bit stratum on a 64 bit system, you can use the x86 nvidia driver prefixed with "linux32" so it doesn't complain about being on a 64 bit system. If you are installing this into a stratum while the system is already running xorg, as long as the stratum in which you are installing these drivers is not the one providing xorg you can probably get away with using the --no-x-check flag.

You are then free to start and use xorg with GPU acceleration.

/dev/fd errors

If you receive errors along these lines:

/dev/fd/N: No such file or directory

where N is a number, this is most likely due to the fact that the device manager you are using is not setting up /dev/fd as some programs expect. This can be solved (for the current session) by running:

To solve this permanently, one could simply add those two lines to /etc/rc.local.

No keyboard or mouse in xorg

If you run startx and do not have a keyboard or mouse:

Root sometimes loses PATH items

There are two common ways to switch from a normal user to root, both of which can potentially change your $PATH away from what is desired. To see the proper path for the root user, login directly to a tty and run echo $PATH.

If you use sudo, make sure you have a "secure_path" line in /etc/sudoers which includes the entire root PATH, such as:

Defaults secure_path="/bedrock/bin:/bedrock/sbin:/bedrock/brpath/pin/bin:/bedrock/brpath/pin/sbin:/usr/local/bin:/opt/bin:/usr/bin:/bin:/usr/local/sbin:/opt/sbin:/usr/sbin:/sbin:/bedrock/brpath/bin:/bedrock/brpath/sbin"

If you use su without the -l flag, consider changing the relevant lines in /etc/login.defs to the following:

ENV_SUPATH PATH=/bedrock/bin:/bedrock/sbin:/bedrock/brpath/pin/bin:/bedrock/brpath/pin/sbin:/usr/local/bin:/opt/bin:/usr/bin:/bin:/usr/local/sbin:/opt/sbin:/usr/sbin:/sbin:/bedrock/brpath/bin:/bedrock/brpath/sbin

ENV_PATH PATH=/bedrock/bin:/bedrock/brpath/pin/bin:/usr/local/bin:/opt/bin:/usr/bin:/bin:/bedrock/brpath/bin:

"grantpt failed" error

If you see "grantpt failed" errors, such as when starting a terminal emulator like xfce4-terminal, this can be remedied by remounting /dev/pts to set the appropriate group number.

First, look at /etc/group and find the number corresponding with the group "tty". Next, add the following to /etc/rc.local:

mount -o remount,gid=tty-gid-number /dev/pts

and the "grantpt failed" error should no be resolved in the next reboot. You can also apply that command to fix the issue for the current session.

time issues

Some distros unmount filesystems before writing the system clock to the hardware clock. This means the global /etc/adjtime file is not available, which in turn means information such as clock drift and whether the hardware clock is in local vs UTC time is not being utilized properly.

To resolve this, you need to manually write to the hardware clock after updating the system clock, or configure your init to do so at very early shutdown before filesystems are unmounted.

For example, after updating the system clock with

Write to the hardware clock with

fstab not mounting

When mount goes to prepare fstab, it will skip target directories which are already a mount point. It may thus become confused by bind mounts Bedrock Linux sets up before fstab is parsed.

However, running a mount command directly, without using fstab, results in it mounting over existing mount points. Thus, to work around this issue, have your init system run the various mount commands separately, such as via /etc/rc.local. For example, instead of mounting /home in an fstab like so:

/dev/sda2 /home ext4 defaults 0 0

consider placing a line in /etc/rc.local (or your init system's equivalent) like so:

mount -odefaults /dev/sda2 /home

Do this for every line which fstab will not mount.

No keyboard in init-choosing menu

Some users have reported that they are unable to utilize the keyboard in the init selection menu. No one on the development team has been able to reproduce this, making it difficult to debug. If you run into this and have the time/capability/interest in helping debug, please bring it up in the IRC channel.

As a work around, configure defaults in /bedrock/etc/brn.conf to what you want and a relatively low timeout.

stratum specific issues

Debian-based Linux distributions

Locale packages

In Debian, if you get errors about locale, try installing the locales-all package.

In Ubuntu, if you get errors about locale, try installing the appropriate language-pack-LANGUAGE (such as language-pack-en) package.


If you get an error about statoverride when using apt/dpkg, it can most likely be resolved by deleting the contents of /var/lib/dpkg/statoverride in the relevant stratum. For example:

Ubuntu/Upstart prior to 15.04 fix

Ubuntu releases prior to 15.04 Vivid Veret utilized Upstart as their init system. Some software was specially modified/configured to expect Upstart as the init system and would fail if running another init system. See this bug report for more information.

If you are using an Ubuntu release prior to 15.04 and do not intend to use Upstart as your init (getting your init from another stratum), you can replace /sbin/initctl with /bin/true to bypass much of the issue, like so:

Note that this does break the ability to boot with that stratum's Upstart init system. Do not do this for Ubuntu 15.04 or later where it has switched to systemd.

Ubuntu/Upstart post 15.04 fix

In the 15.04 Vivid Veret release, Ubuntu switched to systemd. This release includes mechanisms for backwards compatibility with Upstart. Some software bundled with this release (and possibly later releases), such as the default lightdm graphical login manager, assumes /sbin/initctl is in the $PATH for non-root users. However, Bedrock Linux's default $PATH configuration places sbin directories into the $PATH only for the root user. As a work-around, one can ensure initctl is accessible from a bin:

Note that this does break the ability to boot with that stratum's Upstart init system.

Ubuntu resolv.conf

If you have difficulty sharing /etc/resolv.conf in Ubuntu, note that it creates a symlink for that file directing elsewhere. It should be safe to remove the symlink and just create an empty file in its place

Arch Linux

Pacman Filesystem Errors

Errors stating "could not get filesystem information for PATH" when using pacman are normal and mostly harmless so long as you have sufficient free disk space for the operation you are attempting. This seems to be caused by pacman assuming that the mount points it sees are the same as the ones init sees (which would be a fair assumption in almost every case except Bedrock Linux). You can configure pacman to not check for free disk space by commenting out CheckSpace from /bedrock/strata/arch/etc/pacman.conf


Problems with using yum.

Febootstrap does not seem to always include the fedora-release package. This is troublesome, as the package is utilized to access the Fedora repositories. If you find difficulties using yum, you might be able to resolve this by downloading the fedora-release package for the given release (e.g.: fedora-release-17.noarch.rpm) and installing it (from within the Fedora stratum, via brc):

You should then be able to use yum to access Fedora's repositories as one normally would.


Slow boot

CRUX runs depmod on boot which can take a while. It is not strictly needed every boot. To disable this and speed up boot time, edit /bedrock/strata/crux/etc/rc.modules and change

/sbin/depmod -a


# /sbin/depmod -a

CRUX shutdown freeze

CRUX runs /etc/rc.shutdown on shutdown/reboot. When the bru filesystem mounted at /etc - and thus under /etc/rc.shutdown - is killed during shutdown, the shutdown procedure freezes. A work-around for this issue is to move rc.shutdown elsewhere so /etc/ is not ripped out from under it. As root:

CRUX timezone

CRUX's init is hardcoded to expect all timezone files to be in /usr/share/zoneinfo, which can cause problems. To fix this, edit


and change

# Configure system clock
if [ "$TIMEZONE" ]; then
    /bin/ln -snf /usr/share/zoneinfo/$TIMEZONE /etc/localtime


## Configure system clock
#if [ "$TIMEZONE" ]; then
#    /bin/ln -snf /usr/share/zoneinfo/$TIMEZONE /etc/localtime

This will force CRUX to use /etc/localtime, which (with default Bedrock Linux configuration) will be a copy of /bedrock/etc/localtime