Re: [gentoo-user] Emerge -u -k package install order - broken system [SOLVED]

[Alexander Puchmayr]

Am Montag, 6. September 2021, 16:33:32 CEST schrieb Alexander Puchmayr:
> Hi there,
>
> I just tried to upgrade a older installation via binary packages and this
> broke my system. After around 25 packages of almost 300 it stopped with
> error and failing packages.
>
> $ emerge
> Failed to validate a sane '/dev'.
> bash process substitution doesn't work; this may be an indication of a
> broken '/dev/fd'.
> $ ls -l /dev/fd/
> insgesamt 0
> lrwx------ 1 root root 64  6. Sep 14:18 0 -> /dev/pts/0
> lrwx------ 1 root root 64  6. Sep 14:18 1 -> /dev/pts/0
> lrwx------ 1 root root 64  6. Sep 14:18 2 -> /dev/pts/0
> lr-x------ 1 root root 64  6. Sep 14:18 3 -> /proc/27261/fd
>
> --> looks allright, but:
>
> $ bash
> bash: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /lib64/
> libreadline.so.8)
>
> --> system broken(!), cannot start any shell anymore, cannot install
> anything anymore and it's obvious that the system is bricked after reboot
> or even when the ssh session I'm logged in is closed.
>
> It seems like as if sys-libs/readline-8.1_p1-r1-1:0/8::gentoo is installed
> *before* installing a suitable glibc, breaking any binary that has the
> useflag readline (including bash).
>
> Two questions:
> How do I get out of this mess?
> Why does portage not work in correct package order? Portage bug?

The problem was caused by a newly compiled sys-libs/readline as binary 
package. The package itself was compiled on my buildhost by a emerge -auvDN 
world, and when readline was compiled, the latest glibc-2.33 was already 
installed on the buildhost, hence the readline packet had a (implicit) 
dependency to >=glibc-33. Portage does not seem to be aware of that (the glibc 
version is not a dependency of readline), so portage did not care and install 
it at some suitable position later. From the time on that readline was emerged 
from that binary package, all programs linked with it have now that implicit 
dependency of >=glibc-2.33, which is not yet installed (which was 2.28). Bang!

HOW TO FIX THIS BREAKAGE:

For the system recovery I was lucky to have a backup of the old packages, so I 
could extract the readline-tbz2-package file to the temporary directly and copy 
the so files to /usr/local/lib64 (I chose /usr/local/ to avoid overwriting the 
package files) 

Ls -l /usr/local/lib64/
insgesamt 368
lrwxrwxrwx 1 root root     15  6. Sep 14:53 libhistory.so -> libhistory.so.8
lrwxrwxrwx 1 root root     17  6. Sep 15:04 libhistory.so.8 -> libhistory.so.
8.0
-rwxr-xr-x 1 root root  47368  6. Sep 14:53 libhistory.so.8.0
lrwxrwxrwx 1 root root     16  6. Sep 14:53 libreadline.so -> libreadline.so.8
lrwxrwxrwx 1 root root     18  6. Sep 15:04 libreadline.so.8 -> 
libreadline.so.8.0
-rwxr-xr-x 1 root root 325464  6. Sep 14:53 libreadline.so.8.0

Then, I created a ld.so.conf config file to ensure that /usr/local/lib is at 
*first* place:

echo "/usr/local/lib64" >/etc/ld.so.conf.d/10-temporary-fix.conf 
ldconfig

Notes: 
* The config file *must* end with .conf
* Although /usr/local/lib64 is already in the ld.so.conf file, this step is 
necessary to get it at first place; otherwise it is after /lib64 and /usr/
lib64, and ld.so finds the non-working version first
* setting LD_LIBRARY_PATH does not work as ebuild does not forward the 
environment variables from the calling process.

Test it with ldd /usr/bin/bash -- no errors shall be reported, and the 
readline library shall show the /usr/local/lib64 path.

Now, I could emerge glibc-2.33 the usual way (emerge -avk1 glibc), and then 
afterwards remove the temporary ld.so.conf file

rm /etc/ld.so.conf.d/10-temporary-fix.conf 
ldconfig

Test again with  ldd /usr/bin/bash -- the new readline library from /usr/lib64 
and /lib64 shall now be used. 
Now, the libraries from /usr/local/lib can be removed safely.

System recovered!

Best regards,
 Alex