FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 07-07-2012, 07:32 PM
Jonathan Hudson
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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
 
Old 07-07-2012, 07:51 PM
Lukas Fleischer
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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.
 
Old 07-07-2012, 08:17 PM
Jonathan Hudson
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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
 
Old 07-07-2012, 09:17 PM
Christian Hesse
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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);}
 
Old 07-08-2012, 03:37 PM
DR
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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);}
>
 
Old 07-08-2012, 03:46 PM
Christian Hesse
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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);}
 
Old 07-08-2012, 04:17 PM
DR
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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);}
>
 
Old 08-30-2012, 05:14 AM
siyuan
 
Default Glibc 2.16.0-2 and /lib problem : the answer ;)

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
 

Thread Tools




All times are GMT. The time now is 09:18 AM.

VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org