Frequently Asked Questions

The answer to every question is “Read the documentation.” However, for convenience, the most common problem solutions are addressed here.

Basics

Why use Exherbo?

Read about Exherbo’s features.

How do I

…add new repositories?

If the repository is in unavailable then use cave resolve. For repository x11:

# cave resolve repository/x11 -x

automatically creates a repository configuration file for x11 and then syncs the newly created repository.

Make sure that you have /etc/paludis/repositories/repository.conf with the following content:

format = repository
config_filename = /etc/paludis/repositories/%{repository_template_name}.conf
config_template = /etc/paludis/repository.template

and /etc/paludis/repository.template with the following:

format = %{repository_template_format}
location = /var/db/paludis/repositories/%{repository_template_name}
sync = %{repository_template_sync}

To manually add a repository, create a configuration file /etc/paludis/repositories/<repo_name>.conf containing the following:

format = e
location = ${root}/var/db/paludis/repositories/<repo_name>
sync = git://git.exherbo.org/<repo_name>.git

Replace <repo_name> with the name of the repository, and if it’s a third party repository the entire URL specified for sync will differ.

If you always want to sync a branch other than master – such as multilib – specify it in the new configuration file like so:

sync_options = --branch=multilib

If you have not yet configured caching, add the following to /etc/paludis/repository_defaults.conf:

names_cache = ${root}/var/cache/paludis/names
write_cache = ${root}/var/cache/paludis/metadata

Don’t forget to prepend x- to the repository name when syncing for the first time, e.g. for repository foo:

# cave sync x-foo

For more detailed information about repository configuration please consult the Paludis documentation on the e repository format.

…manage packages not in any repository?

If you have the source unpacked and you already performed ./configure && make && make install DESTDIR=/home/user/src/foo-0.3.4/ on it for example, import it as a Paludis-manageable package like so:

# cave import --location /home/user/src/foo-0.3.4/ category/bar 0.3.4 0 --execute

…search for packages in repositories?

To search for all packages containing “vim” in their names, do:

# cave search --name vim

See man cave-search for other search options.

It may be of use to generate a search index and use it, as it speeds up the search greatly. See man cave-manage-search-index for more information.

If you’re looking for a specific package, it is likely quicker to use cave show to look for the package. cave search vim would look through the entire tree, cave show vim would just look for a package named vim. Pay close attention to cave’s suggestions as well; cave show vi will suggest you meant vim instead.

There’s also Summer available to use.

…list installed packages?

# cave show */*::/

…start writing exhereses?

See Exheres for Smarties.

…update my configuration files?

# eclectic config

…rebuild packages which depend on foo/bar?

For example perl:

# cave resolve --reinstall-dependents-of dev-lang/perl nothing

Errors

It is a good idea to carefully read every error message output by Paludis – they are verbose for a reason and easy to understand.

Package masked errors

Masked packages cause Paludis to output the error:

* All versions of 'category/package' are masked. Candidates are:

followed by a list of packages and reasons for the masking. These reasons are explained below, along with what action is needed to fix the problem.

Masked by unavailable

* dev-perl/XML-Simple-2.18:0::unavailable (in ::perl): Masked by unavailable
(In a repository which is unavailable)

Install the perl repository. See: How do I add new repositories?

Masked by unwritten

* net-fs/samba-3.0.32:0::unwritten: Masked by unwritten (Package has not been
written yet)

This means the package hasn’t been written. Try cave show samba, then see: How do I add new repositories?

Masked by platform

* sys-boot/grub-1.96:0::arbor: Masked by platform (~x86)

This means that the package in question has either not been tested on your platform or might not work on your platform. You can bypass this mask by configuring the package for your platform locally:

# echo "sys-boot/grub ~x86" >> /etc/paludis/platforms.conf

If the package works on your platform, please submit a patch to Exherbo adding it to PLATFORMS (see Exheres for Smarties and the documentation on contributing.

pty error when installing a package within a chroot

If you get this error in a chroot:

* When creating pty FDs:
* posix_openpt(3) failed: No such file or directory (paludis::PtyError)

the problem is that /dev/pts is missing in the chroot. Perform the following command to bind-mount /dev properly:

# mount -o rbind /dev /mnt/exherbo/dev

seccomp_init error when trying to resolve a package

*  Could not generate cache for 'sys-apps/systemd-207-r2::arbor', stdout says '' and stderr says 'seccomp_init failed (errno:22 Invalid argument)

This means that your kernel version is too old. In the standard configuration with the seccomp option enabled Sydbox needs a kernel greater than 3.5.0. When following the Install Guide make sure to select SystemRescueCD’s alternative kernel.

The current scm version of Sydbox detects a non-supported kernel and disables seccomp support. So unmasking and updating to this version can help.

Otherwise you might want to disable sydbox via export PALUDIS_DO_NOTHING_SANDBOXY=1 or disable Sydbox’s seccomp option until you have a kernel with a supported version and seccomp support.

Sydbox

Sydbox is a new sandboxing application so it’s quite possible that you may have problems with it. Known problems and solutions are given here.

Why is Sydbox so slow?

This is probably because you’re running a kernel version older than 2.6.29 which has a ptrace() bug. To fix the issue either upgrade your kernel to a recent version or apply this patch.

I upgraded my kernel but Sydbox is still slow. Why?

This is because the program you’re running under Sydbox is either creating a very long directory structure or it’s creating lots of simultaneous threads. For the former issue, it usually helps to disable the lstat() wrapper of Sydbox with esandbox nohack_toolong. For the latter issue, you may try decreasing the number of simultaneous threads.

Why am I getting an access violation in my build directory?

This can happen if your build directory is beneath a symlinked directory or is a symbolic link itself, since mkdir() resolves symbolic links and so does Sydbox.


Copyright 2008, 2009 Jonathan Dahan
Copyright 2010 Ali Polatel