[arch-general] Glibc 2.16.0-2 and /lib problem : the answer ;)
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key. Remove /lib. And create a symlink : ln -sf /usr/lib lib I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core. Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :| -- Frederic Bezies fredbezies@gmail.com
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation? TY in advance.
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded. At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
On Sat, 7 Jul 2012 17:00:06 +0100, Jonathan Hudson wrote:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Apologies, this was meant to be in reply to the "upgrade glibc last" advice. Two systems upgraded, two failures ... not good.
On Sat, Jul 7, 2012 at 6:09 PM, Jonathan Hudson <jh+arch@daria.co.uk> wrote:
On Sat, 7 Jul 2012 17:00:06 +0100, Jonathan Hudson wrote:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Apologies, this was meant to be in reply to the "upgrade glibc last" advice. Two systems upgraded, two failures ... not good.
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote:
On Sat, Jul 7, 2012 at 6:09 PM, Jonathan Hudson <jh+arch@daria.co.uk> wrote:
On Sat, 7 Jul 2012 17:00:06 +0100, Jonathan Hudson wrote:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Apologies, this was meant to be in reply to the "upgrade glibc last" advice. Two systems upgraded, two failures ... not good.
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote:
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed? Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote:
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote:
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed?
Geert
Post event it's hard to tell. I previously removed obsolete firmware, modules and udev directories, then ran the commands from a previous thread (cut and paste, no --force). # pacman -Syu --ignore glibc # pacman -S glibc The current directory was NOT /lib, and as the system is now pretty much as loaded as prior, fuser /usr/lib (or /lib) shows no results. -jh
On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote:
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote:
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed?
Geert
Post event it's hard to tell. I previously removed obsolete firmware, modules and udev directories, then ran the commands from a previous thread (cut and paste, no --force).
# pacman -Syu --ignore glibc # pacman -S glibc
The current directory was NOT /lib, and as the system is now pretty much as loaded as prior, fuser /usr/lib (or /lib) shows no results.
What's the output of `grep '^lib' /var/lib/pacman/local/*/files`?
-jh
On Sat, 7 Jul 2012 21:15:50 +0200, Lukas Fleischer wrote:
On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote:
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote:
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed?
Geert
Post event it's hard to tell. I previously removed obsolete firmware, modules and udev directories, then ran the commands from a previous thread (cut and paste, no --force).
# pacman -Syu --ignore glibc # pacman -S glibc
The current directory was NOT /lib, and as the system is now pretty much as loaded as prior, fuser /usr/lib (or /lib) shows no results.
What's the output of `grep '^lib' /var/lib/pacman/local/*/files`?
/var/lib/pacman/local/glibc-2.16.0-2/files:lib /var/lib/pacman/local/glibc-2.16.0-2/files:lib64 /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/guestfsd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/multipathd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/kpartx_id
On Sat, Jul 07, 2012 at 08:32:36PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 21:15:50 +0200, Lukas Fleischer wrote:
On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote:
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote:
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed?
Geert
Post event it's hard to tell. I previously removed obsolete firmware, modules and udev directories, then ran the commands from a previous thread (cut and paste, no --force).
# pacman -Syu --ignore glibc # pacman -S glibc
The current directory was NOT /lib, and as the system is now pretty much as loaded as prior, fuser /usr/lib (or /lib) shows no results.
What's the output of `grep '^lib' /var/lib/pacman/local/*/files`?
/var/lib/pacman/local/glibc-2.16.0-2/files:lib /var/lib/pacman/local/glibc-2.16.0-2/files:lib64 /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/guestfsd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/multipathd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/kpartx_id
See. Both libguestfs and multipath-tools-git own files in "/lib". You should have dealt with that (i.e. rebuild these and put stuff in "/usr/lib" instead of "/lib") before upgrading.
On Sat, 7 Jul 2012 21:51:43 +0200, Lukas Fleischer wrote:
On Sat, Jul 07, 2012 at 08:32:36PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 21:15:50 +0200, Lukas Fleischer wrote:
On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote:
On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote:
On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote: >You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I did NOT.
Was /lib your current working dir when you ran pacman? Or did any other process have it open so it could not be removed?
Geert
Post event it's hard to tell. I previously removed obsolete firmware, modules and udev directories, then ran the commands from a previous thread (cut and paste, no --force).
# pacman -Syu --ignore glibc # pacman -S glibc
The current directory was NOT /lib, and as the system is now pretty much as loaded as prior, fuser /usr/lib (or /lib) shows no results.
What's the output of `grep '^lib' /var/lib/pacman/local/*/files`?
/var/lib/pacman/local/glibc-2.16.0-2/files:lib /var/lib/pacman/local/glibc-2.16.0-2/files:lib64 /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/ /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/guestfsd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/multipathd.service /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/ /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/kpartx_id
See. Both libguestfs and multipath-tools-git own files in "/lib". You should have dealt with that (i.e. rebuild these and put stuff in "/usr/lib" instead of "/lib") before upgrading.
Even post-event it is interesting to see such expert analysis as to why the system gets broken, tinged with some disappointment that the packaging system does not appear to warn the user apriori of a somewhat unfortunate outcome. Anyway, thanks for your expert diagnosis. I at least now understand why this happened. -jh
On Saturday 07 July 2012 18:18:28 Jan Steffens wrote:
On Sat, Jul 7, 2012 at 6:09 PM, Jonathan Hudson <jh+arch@daria.co.uk> wrote:
On Sat, 7 Jul 2012 17:00:06 +0100, Jonathan Hudson wrote:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Apologies, this was meant to be in reply to the "upgrade glibc last" advice. Two systems upgraded, two failures ... not good.
You used --force (-f) again. http://i.imgur.com/5Zd1w.png
I didn't ;) but it still failed. mc came to rescue as for creating the /lib symlink because # ln -s /usr/lib /lib bash: /bin/ln: No such file or directory Anyway, here's my pacman log [2012-07-07 19:11] Running 'pacman -Syu --ignore glibc' [2012-07-07 19:11] synchronizing package lists [2012-07-07 19:11] starting full system upgrade [2012-07-07 19:11] upgraded lib32-glibc (2.16.0-1 -> 2.16.0-2) [2012-07-07 19:11] Running 'pacman -Suy' [2012-07-07 19:11] synchronizing package lists [2012-07-07 19:11] starting full system upgrade [2012-07-07 19:11] error: problem occurred while upgrading glibc [2012-07-07 19:11] call to execv failed (No such file or directory) [2012-07-07 19:11] upgraded glibc (2.16.0-1 -> 2.16.0-2) [2012-07-07 19:20] Running 'pacman -Suy' [2012-07-07 19:20] synchronizing package lists [2012-07-07 19:20] starting full system upgrade [2012-07-07 19:21] Running 'pacman -S glibc' [2012-07-07 19:21] Generating locales... [2012-07-07 19:21] en_US.UTF-8... done [2012-07-07 19:21] en_US.ISO-8859-1... done [2012-07-07 19:21] Generation complete. [2012-07-07 19:21] upgraded glibc (2.16.0-2 -> 2.16.0-2) -- Arthur Titeica
Jonathan Hudson <jh+arch@daria.co.uk> on Sat, 2012/07/07 17:00:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Same problem here. (Though I have a rescue system on disk, so no real hurt.) /lib still existed in filesystem, though it was empty. -- main(a,b){char*/* Schoene Gruesse */c="B?IJj;M" "EHCX:;";for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On Sun, Jul 8, 2012 at 5:17 AM, Christian Hesse <list@eworm.de> wrote:
Jonathan Hudson <jh+arch@daria.co.uk> on Sat, 2012/07/07 17:00:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Same problem here. (Though I have a rescue system on disk, so no real hurt.)
/lib still existed in filesystem, though it was empty.
The simplest solution might be: /usr/lib/ld-2.16.so ln -s /usr/lib /lib Haven't tested that, though.
-- main(a,b){char*/* Schoene Gruesse */c="B?IJj;M" "EHCX:;";for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
DR <drdarkraven@gmail.com> on Sun, 2012/07/08 23:37:
On Sun, Jul 8, 2012 at 5:17 AM, Christian Hesse <list@eworm.de> wrote:
Jonathan Hudson <jh+arch@daria.co.uk> on Sat, 2012/07/07 17:00:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Same problem here. (Though I have a rescue system on disk, so no real hurt.)
/lib still existed in filesystem, though it was empty.
The simplest solution might be: /usr/lib/ld-2.16.so ln -s /usr/lib /lib Haven't tested that, though.
I think you need to specify full path to ln then: /usr/lib/ld-2.16.so /bin/ln -s /usr/lib /lib or use busybox: busybox ln -s /usr/lib /lib However this does not help if it comes to your mind after you closed the root terminal. ;) -- main(a,b){char*/* Schoene Gruesse */c="B?IJj;M" "EHCX:;";for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On Sun, Jul 8, 2012 at 11:46 PM, Christian Hesse <list@eworm.de> wrote:
DR <drdarkraven@gmail.com> on Sun, 2012/07/08 23:37:
On Sun, Jul 8, 2012 at 5:17 AM, Christian Hesse <list@eworm.de> wrote:
Jonathan Hudson <jh+arch@daria.co.uk> on Sat, 2012/07/07 17:00:
On Sat, 07 Jul 2012 17:35:56 +0200, Arno Gaboury wrote:
On 07/07/2012 05:27 PM, fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
Well, I think I have to do this mistake. I *do* know that forcing wasn't a good idea :|
As I will need to do the update too, can someone explain briefly in this list what shoule be done to avoid such a situation?
TY in advance.
It may still fail
error: extract: not overwriting dir with file lib error: problem occurred while upgrading glibc call to execv failed (No such file or directory) error: command failed to execute correctly error: could not commit transaction error: failed to commit transaction (transaction aborted) Errors occurred, no packages were upgraded.
At this the machine is toast. Hope magic-sysreq is enabled, and you have rescue disk ...
Same problem here. (Though I have a rescue system on disk, so no real hurt.)
/lib still existed in filesystem, though it was empty.
The simplest solution might be: /usr/lib/ld-2.16.so ln -s /usr/lib /lib Haven't tested that, though.
I think you need to specify full path to ln then:
/usr/lib/ld-2.16.so /bin/ln -s /usr/lib /lib
or use busybox:
busybox ln -s /usr/lib /lib
However this does not help if it comes to your mind after you closed the root terminal. ;)
Then maybe one could use LD_LIBRARY_PATH=/usr/lib ?
-- main(a,b){char*/* Schoene Gruesse */c="B?IJj;M" "EHCX:;";for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
fredbezies wrote:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
Careful about that! The current stable kernel (3.4.4-2) still has its modules in /lib/modules/ so if you remove /lib you may not be able to boot!
And create a symlink : ln -sf /usr/lib lib
I think there will be a lot of problem for a lot of users when glibc 2.16.0-x will be uploaded on core.
+1 Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
this worked for me, thank you! fredbezies <fredbezies <at> gmail.com> writes:
Well, Tom gave the answer. Boot on rescue-CD / rescue USB-key.
Remove /lib.
And create a symlink : ln -sf /usr/lib lib
participants (11)
-
"Jérôme M. Berger"
-
Arno Gaboury
-
Arthur Titeica
-
Christian Hesse
-
DR
-
fredbezies
-
Geert Hendrickx
-
Jan Steffens
-
Jonathan Hudson
-
Lukas Fleischer
-
siyuan