__ __ __ \ \_________\ \____________\ \___ \ _ \ _\ _ \ _\ __ \ __\ / \___/\__/\__/ \_\ \___/\__/\_\_\ 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 stratum
strata
, 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-domain
Write 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 LANGUAGE
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 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