__ __ __
\ \_________\ \____________\ \___
\ _ \ _\ _ \ _\ __ \ __\ /
\___/\__/\__/ \_\ \___/\__/\_\_\
Bedrock Linux
Bedrock Linux 1.0beta2 Nyla
This page contains tips, tricks and troubleshooting advice for various software
and strata for Bedrock Linux 1.0beta2 Nyla.
Rather than typing brc , one can shave some keystrokes by
generating aliases for all of the stratumstrata, like so:
for STRATUM in $(bri -l)
do
alias $STRATUM="brc $STRATUM"
alias s$STRATUM="sudo brc $STRATUM"
done
Consider placing that loop, or something similar, in your shell's rc file.
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:
-K option to install
only the kernel.--no-kernel-module option so that it installs both the userland and,
importantly, the kernel module.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.
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.
If you run startx and do not have a keyboard or mouse:
First, don't panic about your system being hard locked. You can regain keyboard control and go to a tty by hitting alt-sysrq-r followed by the keys to go to the tty (such as ctrl-alt-F1). Read up about magic sysrq on linux if you're not familiar with it.
Try using udev if you aren't already (e.g. in contrast to mdev). Boot
with a stratum from some distro that defaults to starting udev at boot
Ensure you have the relevant keyboard and mouse packages installed. On
Debian-based systems, these would be xserver-xorg-input-kbd and
xserver-xorg-input-mouse.
While this should not be necessary if you are using udev, you may want to
consider setting AutoAddDevices and AllowEmptyInput to False in your
xorg.conf file. If this file already exists, it is probably at
/etc/X11/xorg.conf in the stratum that provides startx; otherwise, you'll
have to create it. Try adding the following to the relevant xorg.conf file
and starting the xserver:
Section "ServerFlags"
Option "AutoAddDevices" "False"
Option "AllowEmptyInput" "False"
EndSection
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:
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.
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
ntp-domainWrite to the hardware clock with
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.
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.
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- (such as LANGUAGElanguage-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 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:
ubuntu-stratum dpkg-divert --local --rename --add /sbin/initctlubuntu-stratum/sbin/initctlNote 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.
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:
ubuntu-stratum/usr/local/binNote that this does break the ability to boot with that stratum's Upstart init system.
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
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
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):
heisenbug rpm -i fedora-VERSION.noarch.rpmYou should then be able to use yum to access Fedora's repositories as one
normally would.
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/ and changecrux/etc/rc.modules
/sbin/depmod -a
to
# /sbin/depmod -a
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/etc/rc.shutdown /bedrock/strata/crux/rc.shutdowncrux/etc/rc.shutdownCRUX's init is hardcoded to expect all timezone files to be in
/usr/share/zoneinfo, which can cause problems. To fix this, edit
/bedrock/strata/crux/etc/rc
and change
# Configure system clock
if [ "$TIMEZONE" ]; then
/bin/ln -snf /usr/share/zoneinfo/$TIMEZONE /etc/localtime
fi
to
## Configure system clock #if [ "$TIMEZONE" ]; then # /bin/ln -snf /usr/share/zoneinfo/$TIMEZONE /etc/localtime #fi
This will force CRUX to use /etc/localtime, which (with default Bedrock Linux
configuration) will be a copy of /bedrock/etc/localtime