Thursday, January 31, 2013

Yet another Gentoo update pitfall on my Pi

In general, Gentoo works well on my 512 MB RAM Raspberry Pi, other than the extremely slow rate of new software compilation.

Lately, however, I've noticed that doing a full world update can also lead to unbootability.
Here's an earlier post on Gentoo updating.

Three days ago, I started another full update (which went on for about 24 hours).
At the end, a number of suggestions are made including using

emerge --depclean
to take out orphaned packages.
However, after I ran this command, everything more or less died.
There was no internet connection, I could no longer use simple bash commands such as ls or sudo.
My Conky display was completely messed up.
Many times, this error showed up
sh: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
However, I basically could not do anything in a terminal due to this error which always showed up even for the simplest commands.
As a last resort, I tried a reboot but the very same message appeared multiple times before the boot just stopped.

So over to Google which brought up this forum thread on the very same subject:
It seems upgrading the gcc compiler leads to problems with libgcc_s.so.1 without which many things break.

Now it's worth noting the following in the relevant pages of the Gentoo wiki,


After this you can run emerge --depclean to remove the orphaned dependencies. When this is done, you need to rebuild the applications that were dynamically linked to the now-removed software titles but don't require them anymore.All this is handled with the following three commands:
# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild

However, because everything died (well, almost everything) after I ran emerge --depclean, I was unable to rebuild dynamic links to removed software with revdep-rebuild.

Back to the forum thread where the preferred solution seems to the that suggested in XavierMiller's post.
But, I can't boot not even to a TTy, so how do I apply the suggested commands?

Wait, there's a post at the bottom of the thread (jgerasmus) that refers to Gentoo on a Pi and to chroot into the Pi OS.

But, I cannot see how this is possible.
To chroot into another OS requires having the same architecture (arm) and I don't have any other arm machines (apart from another RPi).
However, I can place the Gentoo SDCard into the card reader of my (x86) EeePC901, then in Ubuntu on the EeePC901, mount both partitions on the SDcard, open a terminal and, as root, issue the following commands:


# cd /media/abcdefghijkl/# ln /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.6.3/libgcc_s.so.1 /usr/lib/

(Note that in  XavierMiller's post, a 'fictitious' lib directory is placed between the directory /4.6.3 and the file libgcc_s.so.1 which does not exist)

Next, I unmounted the card, replaced it in the Pi and booted.
Now everything was fine.

I then proceeded to issue the further commands in XavierMiller's post which were:
# gcc-config -l 4.6.3# rm /lib/libgcc_s.so.1 # ldconfig 
and everything was back to normal but with an updated compiler (gcc).







1 comment:

  1. Things may be "back to normal" because you didn't actually delete the symlink at /usr/lib/libgcc_s.so.1 that you created on your EeePC.

    I've run into the same problem: although `ldconfig -p` reports that libgcc_s.so.1 is accessible at /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so.1, nothing seems to be able to dynamically link against it. I have to put a symlink at /usr/lib/libgcc_s.so.1 in order for anything to find it.

    ReplyDelete