| Troubleshoot | ||
|---|---|---|
 |
Chapter 14. Gentoo Linux |  |
| Troubleshoot | ||
|---|---|---|
| |
Chapter 14. Gentoo Linux | |
Probably you are not alone and not the fist that run in to the problem so see: https://bugs.gentoo.org/ and https://forums.gentoo.org/
On gui applications start them from the console, where errors and warnings appear. Check also logfiles and dmesg.
oowriter to start openoffice
Try also to run them as root to see if there a problem with the permissions.
When crashed type in the console Ctrl + C to quit it.
To have gentoo on older smaller devices as laptops, it is annoying waiting hours to wait until updates of certain packages are done. Solutions could be trash the old device or move away from gentoo. The is also a way out keeping gentoo and the old device and use binary packages:
emerge libreoffice-bin instead emerge libreoffice
emerge firefox-bin instead emerge firefox
emerge rust-bin there is eselect rust list and eselect rust <n> when happy emerge --unmerge rust
It is wise to have the text running by during boot, so it can be observed what is going on and be even interacted. Something could go wrong with X and when you need to login to the graphical login manager, you might be stuck with a non working keyboard or mouse.
After the boot loader has loaded the kernel, the gentoo init scripts are started. When this happens you can press the button I to go into an interactive boot mode.
First some none interruptible tasks are performed, but then the menu comes and shows step by step what service has to be started. For more serious error you can jump directly into the text console and try to fix this way your installation. The command rc-status shows what init scripts are running.
To do the rest and look later for the problem.
emerge --resume --skipfirst
Or
emerge --resume
Or
emerge --skipfirst
Optimists believe that this could fix the problem, since it changes the sequence of the list to be emerged.
Check also that the system time is correct since many builds are based on that.
date
When retrying the package that failed and you try re-emerge it, make sure you type emerge --oneshot <ebuild> or emerge -1 <ebuild> (1 as one, not as l) when the ebuild has been selected
due to dependencies, so it will not be put in the world file and might be deleted once nothing depends anymore on the package. The world file should not be a collection of bad ebuilds. It should
be small and clean.
Try to find out more and where the ebuild fails, see: Install an ebuild using the command ebuild
!!! The ebuild selected to satisfy "app-dicts/myspell-en" has unmet requirements. - app-dicts/myspell-en-20240801::gentoo USE="" ABI_X86="(64)" L10N="-en-AU -en-CA -en-GB -en-US -en-ZA" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( l10n_en-AU l10n_en-CA l10n_en-GB l10n_en-US l10n_en-ZA )
means a L10N use flag must be set as L10N="en-US"
Do USE="-<problematic useflag>" emerge -1<my problem ebuild>
to see if emerge works with disabling (or enabling) the useflag. Avoid doing it globally in /etc/portage/make.conf do it for a specific package in /etc/portage/package.use as:
=<my-problem-category></my problem ebuild><-its version>-doc
Adding the version is recommended, since it can be assumed that the ebuild will emerge in the future.
A more complex problem might look as:!!! The ebuild selected to satisfy "curl" has unmet requirements. - net-misc/curl-8.10.1-r1::gentoo USE="adns alt-svc ftp gnutls hsts http2 http3 imap openssl pop3 progress-meter psl quic samba smtp ssl tftp websockets -brotli -debug -gopher -idn -kerberos -ldap -mbedtls -rtmp (-rustls) -ssh (-sslv3) -static-libs -telnet -test -verify-sig -zstd" ABI_X86="(64) -32 (-x32)" CURL_QUIC="openssl -ngtcp2" CURL_SSL="openssl -gnutls -mbedtls (-rustls)"
The following REQUIRED_USE flag constraints are unsatisfied: curl_quic_openssl? ( !gnutls )
The above constraints are a subset of the following complete expression: quic? ( exactly-one-of ( curl_quic_openssl curl_quic_ngtcp2 ) http3 ssl ) ssl? ( exactly-one-of ( curl_ssl_gnutls curl_ssl_mbedtls curl_ssl_openssl curl_ssl_rustls ) ) curl_quic_openssl? ( curl_ssl_openssl quic !gnutls !mbedtls !rustls ) curl_quic_ngtcp2? ( curl_ssl_gnutls quic !mbedtls !openssl !rustls ) curl_ssl_gnutls? ( gnutls ) curl_ssl_mbedtls? ( mbedtls ) curl_ssl_openssl? ( openssl ) curl_ssl_rustls? ( rustls ) http3? ( alt-svc quic )
curl_quic_openssl? ( !gnutls ) means if CURL_QUIC="openssl" is set then gnutls is not allowed to be set.
To understand the complete expression it is useful to format it to see that different useflags have different restrictions:
quic? ( exactly-one-of ( curl_quic_openssl curl_quic_ngtcp2 ) http3 ssl )
ssl? ( exactly-one-of ( curl_ssl_gnutls curl_ssl_mbedtls curl_ssl_openssl curl_ssl_rustls ) )
curl_quic_openssl? ( curl_ssl_openssl quic !gnutls !mbedtls !rustls )
curl_quic_ngtcp2? ( curl_ssl_gnutls quic !mbedtls !openssl !rustls )
curl_ssl_gnutls? ( gnutls )
curl_ssl_mbedtls? ( mbedtls )
curl_ssl_openssl? ( openssl )
curl_ssl_rustls? ( rustls )
http3? ( alt-svc quic )
adding
net-misc/curl -openssl
to /etc/portage/package.use is not enough to solve it since CURL_SSL and CURL_QUIC will still have a conflict. This needs to be resolved there are different ways to do it:
Name the use flags explicitly:
net-misc/curl -openssl -curl_ssl_openssl curl_ssl_gnutls -curl_quic_openssl curl_quic_ngtcp2
or remove all use flags and add the ones desired
net-misc/curl -openssl CURL_SSL: -* gnutls CURL_QUIC: -* ngtcp2
or since CURL_SSL and CURL_QUIC might be used by other packages:
*/* CURL_SSL: -* gnutls */* CURL_QUIC: -* ngtcp2 net-misc/curl -openssl
Slots allow that a package can be installed multiple times. This is common for some packages as (version 2 and 3) and kernel sources. However there are many packages or versions that can not be installed at the same time. This can cause a dependency conflict and therefore the system refuses to be updated. Possible solutions are:
Useflags that are not enabled by the new version but got enabled by the old version and package wants also to have the useflag enabled for the updated package. It refuses to accept the new package due to the missing useflag. The solution is to also enable the useflag for the updated package.
This is like what was first the egg or the chicken? One ebuild can not be installed because an other one is missing, however the missing ebuild can also not be installed since the same first ebuild is missing. A way out is playing with the USE flags and call as: USE="-doc" emerge<one of the ebuild>
When updates fails, the reason is reported, however in a form requiring detailed know how. If a library is missing, then it is probably really not there. Check this as ls /usr/lib | grep 'libssl.so' and do not provide a version number, so all versions are reported.
If the version is not there but others, it is an update bug. You can try to fix it making a symbolic link of the missing library to the so version that has no version. Then try updating your system and emerge @preserved-rebuild (or the old way revdep-rebuild). When everything done remove your manually added symlinks.
If emerge fails due to an MD5 checksum error (or digest verification failure) you can manually delete the file in /var/cache/distfiles and redo emerge from the same mirror or modify the mirror list in
/etc/make.conf to try it from an other mirror and redo a emerge --sync again. Inside portage each ebuild has it own manifest file containing all checksums of
all files used during emerge, alternatively you could update yourself the manifest file. However this is a dirty hack that gets wiped out next time you emerge --sync your portage and the reason remains why
manifest did not match, however it might solve your problem:
ebuild /var/db/profile/gentoo/media-video/realplayer/realplayer-11.0.0.4028-r1.ebuild digest
Instead emerge ---update -- deep world directly try first emerge --update --deep system
One ebuild can not be updated because an other ebuild blocks the update. Check if the other one who blocks is part of the system profile emerge -pv --unmerge <package that blocks> if not unmerge it.
Check also if /var/lib/portage/world is clean. Clean means that just files are there that you know and that you manually and intentionally have
emerged.
Emerge does the installation in two steps. The installation goes into a temporary directory and then the merge follows to put it into the real root system. If install tries to write directly into the real root system, then the sandbox gives access violation with permission denied.
This feature can be turned off by calling FEATURES="-sandbox" emerge v4l-dvb-hg . This should just be considered when no other solution can be found.
It is possible but not recommended at all to have this permanently active and put the line
FEATURES="-sandbox"
in
/etc/portage/make.conf.
perl goes in /usr/lib64/perl5 where the installed versions can be seen.
Special updating perl procedures might remove lots of perl emerge problems. Commands for that are perl-cleaner --all or perl-cleaner --reallyall or emerge gentoo-perl-helpers that creates ebuild sets to clean and update a perl version.
The reason can be that the system runs out of memory. Check if dmesg shows running out of memory.
Adding additional swap space, either as a swap partition or a swap file might be the solution.
A swapfile or partition might be required when huge packages are getting complied. The swap could be on an external USB Harddisk. swapon /dev/sd<?>.
Or consider to emerge binary packages as emerge rust-bin and emerge firefox-bin
Use /etc/portage/package.env and /etc/package/env to Create an environment to emerge it with less CPUs involved to not run out of RAM
Or think about if it is time to buy a new device
After removing some programs it can happen that when you do emerge --update --deep world --pretend, you see that emerge wants to emerge stuff that you don't want. The reason is that there are still some packages or libraries installed that want these updates.
Dependencies go in two directions.
In the down direction a package required to have other packages so it emerges. To find those ebuilds take one of the unwanted ebuilds that emerge --update --deep world --pretend lists and do a equery depends =kdelibs-3.5.10-r6. As result a list of ebuilds appear that still desire kdelibs-3.5.10-r6. Using a gui portage tool (as porthole) you can check if those ebuilds are installed and when so un-merge them using the appropriate version.
If the up direction the package is required by an other package installed and this packages can be found using emerge with the -t option
Also things as USE="-systemd" emerge --update --deep world --pretend can help
Check also files in /etc/portage as /etc/portage/package.use
When having troubles with big ebuilds also dependent ebuilds need to be re-emerged. The following sample shows how to do this for the drivers related to xorg-server emerge -1tav $(qlist -IC x11-drivers)
Example how to build dependencies that depend on a lib
revdep-rebuild --soname libncurses.so.5
/var/lib/portage/world is a file containing a list of all packages emerged. A clean Gentoo installation must have a clean world file! See the wold file section for more details
Try emerge -ea <package> that installs the package with all necessary packages in the tree.
A library is required but the library is obsolete or missing, so compile everything that has dependencies to that library with the hope that the dependencies will be removed: revdep-rebuild --library '<path to and library>'
If revdep-rebuild exits due to an error and gets restarted afterwards, the checking phase is skipped and everything will be re-emerged. To reset this call it as revdep-rebuil -i. This ignores the temporary files. Alternatively you could do rm /var/cache/revdep-rebuild/*.rr
When having tremendous conflicts after emerge --sync it is worth to check for installed unavailable packages. That might can get updated or otherwise unmerged manually.
Do not unmerge system packages
This however can end up in a disaster. A way out might be:
emerge -e world
Will re-emerge world (containing system) completely and take hours.
| |
|
|
| Advanced checks |
|
Chapter 15. Programming |
