Tag Archive: pacman


Server hickup

Filed Under: English by andre — Leave a comment
2 February 2013

As I’ve been telling before, due the increased number of sites on my server, I’m hitting its limits. Mainly the fact the server got only 1 GB of RAM is putting limitations. Recently the server was acting up again, and I assumed it was caused by resource limits, therefore I attempted to tune the configuration a little more to use less resources, without any luck.

I started to notice this problem showed different characteristics the problems I’ve been experiencing before. Mainly because it seemed also to influence the mail system rather then just the webserver. The problem seemed to be linked to the mysql server. Restarting the server didn’t work as it should. Defenately something with mysql…. So I decided to start mysql in a console to look and I saw

mysqld: Disk is full writing './mysql-bin.~rec~' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)

The problem: the root file system was full: In all the time the server was running, of course I have frequently been upgrading the system. During all this time, packages were downloaded to /var/cache/pacman/pkg and never removed. So… it was eating a couple of gigabytes…. and the root file system is just a small filesystem, just for the OS. The data is elsewhere.

Another mystery solved.

Tags: , ,
Comment

Some more pacman

Filed Under: English by andre — Leave a comment
23 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.

Tags: , , ,
Comment

Pacman trouble again

Filed Under: English by andre — Leave a comment
18 July 2012

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?

Tags: , ,
Comment

pacman problems in the arch

Filed Under: English by andre — Leave a comment
28 April 2012

When I tried to upgrade my system the other day I got the message

:: The following packages should be upgraded first :
pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n]

This is nothing unusual per se, but what happened next was

resolving dependencies…
looking for inter-conflicts…
error: failed to prepare transaction (could not satisfy dependencies)
:: gcc: requires gcc-libs=4.7.0-3

The solution is

[root@hp ~]# pacman -S libtool gcc gcc-libs
:: The following packages should be upgraded first :
pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n] n

So, you have to specify libtool, gcc and gcc-libs at one time, else you will
run into a cross dependency problem pacman seems to be unable to solve itselve.
When it asks to upgrade pacman first, you should say no.

After this, you can upgrade pacman, and the rest of your system without issues.

Tags: ,
Comment