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

Bedrock Linux 1.0alpha3 Bosco

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

Bedrock Linux 1.0alpha3 Bosco Tips, Tricks and Troubleshooting

This page contains tips, tricks and troubleshooting advice for various software and clients for Bedrock Linux 1.0alpha3 Bosco.

General issues

Proprietary Nvidia Drivers

The official Nvidia proprietary drivers works well in Bedrock Linux if set up properly. Various things to keep in mind:

and move or delete the file (as root).

The "linux32" command ensures the driver doesn't complain about being in a 64-bit environment when installing. Do not try this without --no-kernel-module if you have a 64-bit kernel.

DNS from the core does not work

It seems that even if ldd reports busybox was statically compiled, when compiled against glibc, the DNS libraries do not seem to be pulled it and functionality such as ping or wget do not seem to work. This is considered a minor issue as a client should be able to provide this functionality such that the core Bedrock Linux does not need it. If you insist on remedying it, you have two choices:

TODO: do the above and provide the libraries in the instructions here

/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 in the core Bedrock such that it is run every time Bedrock Linux is booted.

No keyboard or mouse in xorg

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

Mount Table Unreadable

If you are receiving errors such as

df: Warning: cannot read table of mounted file systems

This could be because the application (such as df) is attempting to read information from /etc/mtab, which is not being maintained. What you can do instead, however, is symlink /proc/mounts (which is being maintained) to /etc/mtab, like so:

ln -f -s /proc/mounts /etc/mtab

This should remedy the issue. If you like, you could run this in all of your clients:

brl ln -f -s /proc/mounts /etc/mtab

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, consider adding a "secure_path" line to /etc/sudoers which includes the entire root PATH, such as:

Defaults secure_path="/bedrock/bin:/bedrock/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/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:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/bedrock/brpath/bin:/bedrock/brpath/sbin
ENV_PATH PATH=/bedrock/bin:/usr/local/bin:/usr/bin:/bin:/bedrock/brpath/bin

Note that

Thus, neither of these items will resolve anything in the core Bedrock, only in clients. In the core, you could:

time issues

Bedrock manages the timezone through the TZ variable which is set in rc.conf. This should be picked up by /etc/profile and, by extension, your shell and every other program on your system irrelevant of client, so long as they all follow the POSIX TZ standard. If you set this as described, it should not require any tweaking per client. If you are having trouble with your timezone, see if maybe you are setting $TZ elsewhere such as your shell's rc file (e.g.: .bashrc) or are using a shell that is not parsing /etc/profile (brsh should parse /etc/profile)

To set the time, use an application such as ntpdate from a client, then run hwclock -s to save the result to your hardware clock so it sticks across reboots.

Client specific issues

Debian-based Linux distributions

Ubuntu/Upstart fix

Ubuntu uses Upstart for its init system. Many services in Ubuntu have been modified to depend on init to be specific to Upstart and refuse to operate otherwise. This means they do not work in chroots out of the box. See the here for more information. One way to alleviate this is to run the following two commands as root (within the Ubuntu client, via using brc for each command or brc to open a shell in the client and run it from the shell):

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 (from within the client - ie, /var/chroot/client/var/lib/dpkg/statoverride from outside). Leave an empty file there. This seems to occur due to the fact an expected daemon is not running.

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

If you get errors about could not get filesystem information for PATH when using pacman, this is 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 /var/chroot/arch/etc/pacman.conf

Gentoo Linux

/var/tmp Out of Space

If you get errors when updating Gentoo that /var/tmp is out of space, this is most likely because portage uses /var/tmp to compile everything. If /var/tmp is configured in brclients.conf to be shared, and you have your core Bedrock system on a separate, smaller partition, then this error is because /var/tmp is stored on the smaller core Bedrock partition. To fix it, just unshare /var/tmp from Gentoo in your brclients.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 respolve this by downloading the fedora-release package for the given release (e.g.: fedora-release-17.noarch.rpm), and install it thusly (from within the Fedora client, via brc):

rpm -i fedora-VERSION.noarch.rpm

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