Archive for July, 2012


As I also have to upgrade the packages on my server, and the /lib exist problem, when forcing installation, caused some mess on my desktop machine, I really have to do something different on my server when upgrading the packages there.

http://www.linuxquestions.org/questions/linux-newbie-8/arch-pacman-su-error-glibc-lib-exists-in-filesystem-4175418135/ gave me some solution:

$ grep '^lib/' /var/lib/pacman/local/*/files

To remove all packages except glibc which install in /lib. In the case of the server, these were gcc-multilib libtool-multilib and lib32-glibc. In other words, the 32 bit support parts.

So, in order to revert the system to 64 bit, we use:

# pacman -S -d gcc-libs

To use only the 64 bit versions of the gcc-libs. The option -d is added to not check for dependencies. Please note I have switched to using pacman directly in stead of using yaourt. This feels a little safer when doing operations that could destroy the system.

# pacman -R lib32-gcc-libs lib32-libltdl lib32-glibc

However upgrading the system still fails due the existance of /lib. I have removed all packages that exist in /lib, thus this was not the problem. It seems, the problem was the existance of the directory /lib/yaourt. Moving this directory temporary outside /lib makes the upgrade work. So, when it’s finished, the services that are affected are restarted, the removed packages have been restored, I can move the yaourt directory back where it belongs.

So, now, we know the solution for the /lib exists problem which has been appearing on the internet on many places, just move the yaourt directory (temporary) elsewhere and perform the upgrade through pacman directly.

After the upgrade, it seems the /lib/yaourt directory has been recreated.

Pacman trouble again, This time, glibc is the culprit.

glibc
[###########################################] 100%
warning: /etc/locale.gen installed as /etc/locale.gen.pacnew
error: extract: not overwriting dir with file lib
error: problem occurred while upgrading glibc
call to execv failed (Bestand of map bestaat niet)
error: command failed to execute correctly
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

Well….. this leaves me with a broken C library. When this happens, do not close any windows or program as without the C library in place, it’s very hard to open a new shell. So…. since I was running pacman to upgrade stuff, which failed, I did have a root shell available, which is essential to fix this problem.

So, the situation, no program would start. It would just say file not found, but what file? Appearently the dynamic linker was broken. Running a program with the dynamic linker manually worked. For example
/lib64/ld-linux-x86-64.so.2 /bin/ls

So, what we have to do… replace the required files manually. So, wehere to get them? We have to know pacman downloads its packages to /var/cache/pacman/pkg/. So, the file we are interested in is /var/cache/pacman/pkg/glibc-2.16.0-2-x86_64.pkg.tar

So, we are going to create a directory and extract the files. As we do have a broken dynamic linker, we need to prefix it manually


/lib64/ld-linux-x86-64.so.2 /bin/mkdir blaat
cd blaat
/lib64/ld-linux-x86-64.so.2 /usr/bin/xz -d /var/cache/pacman/pkg/glibc-2.16.0-2-x86_64.pkg.tar.xz
/lib64/ld-linux-x86-64.so.2 /bin/tar -xvf /var/cache/pacman/pkg/glibc-2.16.0-2-x86_64.pkg.tar

Now, replacing the files…

/lib64/ld-linux-x86-64.so.2 /bin/cp lib64/* /lib64

which leads to the next problem. We have mixed library versions now! We have replaced the /lib64/ld-linux-x86-64.so.2 file however the /usr/lib/libc.so.6 is still the old version. Now we cannot execure anything! Lucky me, busybox provides statically linked binaries, which can solve this problem. Remember when I said not to close any window. I still had a browser open, so I could download this. Then using busybox, prefixing the path to busybox so copy the content of usr/lib to /usr/lib, and finally lib to /lib, making the system work again.

This my friends, was another day on ArchLinux. Feels like being on safari, doesn’t it?

As I mentioned yesterday, due the spam prevention plugin (NotCapatcha), this site will place a PHP Session cookie on your machine. Due that fact I have installed the Cookie Control to notify you about this. This morning, when visiting my blog using Firefox, I noticed my Ghostery giving me a blocking alert. I was like WTF?!?!? So it appears this Cookie Control plugin uses someth8ng called geoPlugin.

I can select to only view the privacy notice to visitors from specific countries. That’s probably the reason this geoPlugin is used, as it is a plugin to provide geographic locations. However I do not use this feature, and therefore it is not necessary to be loaded. I will see if I can remove this from the Cookie Control. But that will have to be later… I got plans for this afternoon.

My apologies for serving this on my blog.