Re: [arch-general] Still Glibc problems

[John Briggs]

On Sat, Jul 21, 2012 at 02:11:00PM -0700, David Benfell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 07/20/12 15:34, John Briggs wrote:
> > General Discussion about Arch Linux 
> > 
> > 
> > On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote:
> >>> pacman -Su
> >>> 
> >> 
> >> Not OK:
> >> 
> >>> [root@shack n7dr]# pacman -Su :: Starting full system
> >>> upgrade... resolving dependencies... looking for
> >>> inter-conflicts...
> >>> 
> >>> Targets (1): glibc-2.16.0-2
> >>> 
> >>> Total Installed Size:   33.94 MiB Net Upgrade Size:   0.83
> >>> MiB
> >>> 
> >>> Proceed with installation? [Y/n] (1/1) checking package
> >>> integrity
> >>> [##]
> >>> 100% (1/1) loading package files
> >>> [##]
> >>> 100% (1/1) checking for file conflicts
> >>> [##]
> >>> 100% error: failed to commit transaction (conflicting files) 
> >>> glibc: /lib exists in filesystem Errors occurred, no packages
> >>> were upgraded. [root@shack n7dr]#
> > 
> > After much investigation the only workaround for this problem I
> > could discover and I have used on my three computers this week is:
> > 
> > system reboot   : updates system with new packages. 
> > This : step is
> > critical or you could end up with : a borked system
> > 
> > # pacman -Sfu   : This forces the loading of 
> > glibc-2.16.0-2 : but
> > errors out because /lib directory exists ignore errors  
> > : on the
> > system.
> > 
> > # /usr/lib/ld-2.16.0.so /bin/rm -r /lib
  /usr/lib/ld-2.16.so

> > 
> > # /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib
  /usr/lib/ld-2.16.so

> > 
> > system reboot
> > 
> > DANGER: If the above procedure is not followed exactly you can bork
> > your system and it will need a complete rebuild.  An other
> > workaround is:
> > 
> > # system reboot
> > 
> > # pacman -Sfu
> > 
> > Ignore errors use a live CD/USB and boot Linux. # mkdir /archroot
> > 
> > # mount /dev/ /archroot : where  is the root partition
> > 
> > # cd /archroot
> > 
> > /archroot]# rm -r lib
> > 
> > /archroot]# ln -s usr/lib ./lib
> > 
> > system reboot
> > 
> > HTH
> > 
> > John
> > 
> > PS: I have not read the complete thread so I do not know if someone
> > else has already offered these solutions. JEB
> > 
> 
> You're using some tricks I didn't know about (there are, I'm sure,
> lots in that category), but I don't see how this procedure addresses
> the problem of other packages having files in /lib.
> 

It doesn't I didn't have other packages having files in /lib.
One of my machines uses wifi and I had to update the carl9170-fw package so
it was installed to /usr/lib. The residual entries in /lib was the modules
and firmware directories.

I was only seeking to get these systems working not on why they weren't
according to the news. I followed the links to manual installation and got
most of my information from there and I followed most of the sublinks too.
I made an error in the above procedures:
all instance of /usr/lib/ld-2.26.0.so should be replaced with
/usr/lib/ld-2.16.so

The system reboot is the critical step as it sets the system into a known
configuration and prevent it from borking on the next step.

If it is critical to know what packages are causing the problems use 

# pacman -Sfu and see whats left in the /lib directory or subdirectories.

You'll probably  find its the proprietary drivers that you use.

Regards

John

Re: [arch-general] Still Glibc problems

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/12 15:34, John Briggs wrote:
> General Discussion about Arch Linux 
> 
> 
> On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote:
>>> pacman -Su
>>> 
>> 
>> Not OK:
>> 
>>> [root@shack n7dr]# pacman -Su :: Starting full system
>>> upgrade... resolving dependencies... looking for
>>> inter-conflicts...
>>> 
>>> Targets (1): glibc-2.16.0-2
>>> 
>>> Total Installed Size:   33.94 MiB Net Upgrade Size:   0.83
>>> MiB
>>> 
>>> Proceed with installation? [Y/n] (1/1) checking package
>>> integrity
>>> [##]
>>> 100% (1/1) loading package files
>>> [##]
>>> 100% (1/1) checking for file conflicts
>>> [##]
>>> 100% error: failed to commit transaction (conflicting files) 
>>> glibc: /lib exists in filesystem Errors occurred, no packages
>>> were upgraded. [root@shack n7dr]#
> 
> After much investigation the only workaround for this problem I
> could discover and I have used on my three computers this week is:
> 
> system reboot : updates system with new packages. This : step 
> is
> critical or you could end up with : a borked system
> 
> # pacman -Sfu : This forces the loading of glibc-2.16.0-2 : 
> but
> errors out because /lib directory exists ignore errors
> : on the
> system.
> 
> # /usr/lib/ld-2.16.0.so /bin/rm -r /lib
> 
> # /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib
> 
> system reboot
> 
> DANGER: If the above procedure is not followed exactly you can bork
> your system and it will need a complete rebuild.  An other
> workaround is:
> 
> # system reboot
> 
> # pacman -Sfu
> 
> Ignore errors use a live CD/USB and boot Linux. # mkdir /archroot
> 
> # mount /dev/ /archroot   : where  is the root partition
> 
> # cd /archroot
> 
> /archroot]# rm -r lib
> 
> /archroot]# ln -s usr/lib ./lib
> 
> system reboot
> 
> HTH
> 
> John
> 
> PS: I have not read the complete thread so I do not know if someone
> else has already offered these solutions. JEB
> 

You're using some tricks I didn't know about (there are, I'm sure,
lots in that category), but I don't see how this procedure addresses
the problem of other packages having files in /lib.


- -- 
David Benfell
benf...@parts-unknown.org


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQCxrjAAoJELT202JKF+xpmCEP+wTlt5/a3ZRgtZT+1/ZsBT97
XNFK4QTOaq3bb+kHO1pMkarvq3e52GoSIMGysqRSWAhiqeZ40aOwqDcpUmdpB7VM
fqLeY/0izJmR9lsbSAKiyH3JvjzdcLUdR/qJnTkihOY+MzO9QwOtNrn+QzoT26yo
+SJvoDGPjOisgL+sPuK8QfZP1ET4Avu4xxI7bv+kGAJj6QNLvMf5Kj30GF1d8a0/
F0cxKRV55cR9pthTx9SLceOhyB/IPMWQBfj7Ng2ONXoJpkQF5+/3BahDBjXV5h9R
c5zlNt0nC8ckucyGcstVq9eKCIAfrBxtq+k995Ty6ZQEJfwUnTRYkU61YeN4NZxT
olMIWMbqyF5YnaEDEsQ75x1m/9BwVz4c2HDs7Exe6yCk3+HNGN4opTjyU7n62zvl
CWu/UFzoU+TcmsqBK7tklE1R7JdwjY8z/zVRHl8cL+kw/PM2yJqZxnuVjTv2vGDL
x0fc8MFGpa0HGdBmOP0IqglbW6AzqY89TXiG1prhGAzUZFAsqSgAAkK1isIwKa1P
4msQz/9KGftEjIEtUTXJ4GqCc02HTHYM4bJno0d47EA2bJNnkoFGvNkYKc00eFxE
Zf6I+pkd/6RQTa3vixMsFTVV+TgZb1CIqg91rrDYfdxv/ICKqoGSUTsLuEt7QSXd
yf6dLhAvtCh4cH2dRiqK
=R7sP
-END PGP SIGNATURE-

Re: [arch-general] Still Glibc problems

[Baho Utot]

On 07/21/2012 11:24 AM, Tom Gundersen wrote:

On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans  wrote:

I *think* that this means that in fact glibc owns all the files.

It means that no other package owns any files. It might still be that
there are files in /lib that are not owned by any package. pacman -Qo
/lib/* should tell you (or simply "ls /lib" and compare with the list
you pasted in your previous email).

-t



find /lib -exec pacman -Qo -- {} + 2>&1 | grep 'No package'

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Ariel Popper said the following at 07/21/2012 09:24 AM :

> My reading comprehension may be lacking, but did you check to see if 
> there are any files in /lib that are *not* owned by any package?
> 
> find /lib -exec pacman -Qo -- {} +
> 
> Commonly there are some directories like /lib/modules or in my case a 
> stray udev file that didn't get cleaned up automatically.
> 
> Ariel
> 

I concluded that I should just cross my fingers and delete /lib/modules. That
worked. Thank you to everyone for helping me with this. Sorry it took so long.

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Sat, Jul 21, 2012 at 4:57 PM, D. R. Evans  wrote:
> I *think* that this means that in fact glibc owns all the files.

It means that no other package owns any files. It might still be that
there are files in /lib that are not owned by any package. pacman -Qo
/lib/* should tell you (or simply "ls /lib" and compare with the list
you pasted in your previous email).

-t

Re: [arch-general] Still Glibc problems

[Ariel Popper]

Maybe I'm missing an instruction somewhere, but I don't see it.

   Doc



My reading comprehension may be lacking, but did you check to see if 
there are any files in /lib that are *not* owned by any package?


find /lib -exec pacman -Qo -- {} +

Commonly there are some directories like /lib/modules or in my case a 
stray udev file that didn't get cleaned up automatically.


   Ariel

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Norbert Zeh said the following at 07/20/2012 05:34 PM :

>>
>>> pacman -Su
>>>
>>
>> Not OK:
>>
>>> [root@shack n7dr]# pacman -Su
>>> :: Starting full system upgrade...
>>> resolving dependencies...
>>> looking for inter-conflicts...
>>>
>>> Targets (1): glibc-2.16.0-2
>>>
>>> Total Installed Size:   33.94 MiB
>>> Net Upgrade Size:   0.83 MiB
>>>
>>> Proceed with installation? [Y/n] 
>>> (1/1) checking package integrity
>>>   
>>> [##]
>>>  100%
>>> (1/1) loading package files 
>>>   
>>> [##]
>>>  100%
>>> (1/1) checking for file conflicts   
>>>   
>>> [##]
>>>  100%
>>> error: failed to commit transaction (conflicting files)
>>> glibc: /lib exists in filesystem
>>> Errors occurred, no packages were upgraded.
> 
> I got the same error at that point.  What this means is that you either have
> some unowned (by any package) files in /lib (/lib/modules/* is a good 
> candidate)
> or you have some other packages (most likely from AUR) owning files under 
> /lib.
> The wiki page explains well how to look for them.  At least, I followed those
> instructions and managed to identify the packages that blocked the upgrade.  
> The
> key here really seems to be to make sure that glibc is the only package which 
> at
> this point owns anything under /lib.  I think in my case it also helped to
> uninstall some packages and reinstall them after the glibc upgrade.  Keep
> pushing, you're almost there ;)

The instructions (as so often) are not clear.



If after this the "pacman -Su" still has conflicts with /lib, this is likely
because a package on your system other than glibc owns files in /lib. Such
packages can be detected using:

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



So this gives:

> root@shack tmp]# grep '^lib/' /var/lib/pacman/local/*/files
> /var/lib/pacman/local/glibc-2.15-10/files:lib/
> /var/lib/pacman/local/glibc-2.15-10/files:lib/ld-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/ld-linux.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libBrokenLocale.so.1
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libSegFault.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libanl-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libanl.so.1
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libc-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libc.so.6
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libcidn-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libcidn.so.1
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libcrypt-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libcrypt.so.1
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libdl-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libdl.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libm-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libm.so.6
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libmemusage.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnsl-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnsl.so.1
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_compat-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_compat.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_db-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_db.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_dns-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_dns.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_files-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_files.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_hesiod-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_hesiod.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nis-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nis.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nisplus-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libnss_nisplus.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libpcprofile.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libpthread-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libpthread.so.0
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libresolv-2.15.so
> /var/lib/pacman/local/glibc-2.15-10/files:lib/libresolv.so.2
> /var/lib/pacman/local/glibc-2.15-10/files:lib/librt-2.

Re: [arch-general] Still Glibc problems

[John Briggs]

General Discussion about Arch Linux 


On Fri, Jul 20, 2012 at 03:41:08PM -0600, D. R. Evans wrote:
> > pacman -Su
> > 
> 
> Not OK:
> 
> > [root@shack n7dr]# pacman -Su
> > :: Starting full system upgrade...
> > resolving dependencies...
> > looking for inter-conflicts...
> > 
> > Targets (1): glibc-2.16.0-2
> > 
> > Total Installed Size:   33.94 MiB
> > Net Upgrade Size:   0.83 MiB
> > 
> > Proceed with installation? [Y/n] 
> > (1/1) checking package integrity
> >   
> > [##]
> >  100%
> > (1/1) loading package files 
> >   
> > [##]
> >  100%
> > (1/1) checking for file conflicts   
> >   
> > [##]
> >  100%
> > error: failed to commit transaction (conflicting files)
> > glibc: /lib exists in filesystem
> > Errors occurred, no packages were upgraded.
> > [root@shack n7dr]# 

After much investigation the only workaround for this problem I could
discover and I have used on my three computers this week is:

system reboot   : updates system with new packages. This
: step is critical or you could end up with
: a borked system

# pacman -Sfu   : This forces the loading of glibc-2.16.0-2 
: but errors out because /lib directory exists 
ignore errors   : on the system.

# /usr/lib/ld-2.16.0.so /bin/rm -r /lib

# /usr/lib/ld-2.16.0.so /bin/ln -s /usr/lib /lib

system reboot

DANGER: If the above procedure is not followed exactly you can bork your
system and it will need a complete rebuild.

An other workaround is:

# system reboot

# pacman -Sfu

Ignore errors use a live CD/USB and boot Linux. 
# mkdir /archroot

# mount /dev/ /archroot : where  is the root partition

# cd /archroot

/archroot]# rm -r lib

/archroot]# ln -s usr/lib ./lib

system reboot

HTH

John

PS: I have not read the complete thread so I do not know if someone else
has already offered these solutions. JEB
 

Re: [arch-general] Still Glibc problems

[David C. Rankin]

On 07/20/2012 04:45 PM, Baho Utot wrote:
> On 07/20/2012 12:46 PM, Tom Gundersen wrote:
>> On Jul 20, 2012 6:08 PM, "Baho Utot"  wrote:
>>> On 07/20/2012 10:47 AM, Tom Gundersen wrote:
 On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans  wrote:
> There's nothing on this system that hasn't come from either AUR or the
> official arch repositories, so I don't know why I'm having any problems
>> at all :-(
 I have seen people having problems because they installed packages
 from repos that they no longer have active (typically multilib), make
 sure to either remove any "stale" packages or re-enable any repos so
 you get all the most recent updates.
>>>
>>> I had a desktop system hosed that only packages in core, extra and
>> community installed.
>>
>> I never heard of anyone actually hosing their system without using --force.
>> What happened? (I'm assuming you don't use testing?).
>>
>> -t
> 
> No I didn't use testing.
> Followed the news release..rebootedsystem borked.
> 
> 
> 
> 

Tom, Baho,

  After Updating 3 boxes and created 3 new arch chroots, you do have manual
intervention required in just about every case if you have ever used mkinitcpio
to rebuild initramfs (leaves old module trees in /lib/modules) or if you have
ever used virtualbox (old vb modules left in /lib/modules/misc or
/lib/modules/kernel/misc) udev-compat is also a problem. Just pacman -R that.

  Then after you do the initial pacman -Syu --ignore glibc, you need to manually
pick though lib and make sure there is _nothing_ but glibc files in it. (no
empty dirs, no links, no nothing) Then you can do the final pacman -Syu

  Also, if you attempt to create or update an arch chroot -- make sure you have
no stale repos in pacman.conf. The install will fail and half your system will
be mounted under the chroot dir.  There is no way to update an arch chroot with
the glibc 2.15->2.16 update. Just create a new one.

  Hope some of this helps..

-- 
David C. Rankin, J.D.,P.E.

Re: [arch-general] Still Glibc problems

[Norbert Zeh]

D. R. Evans [2012.07.20 1541 -0600]:
> Norbert Zeh said the following at 07/19/2012 06:08 PM :
> 
> > 
> > Well, the filesystem instructions are older and applied at the time the 
> > glibc
> > upgrade was not an issue yet.  Combining the two instructions, I would 
> > guess the
> > following should work:
> > 
> > pacman -Syu --ignore filesystem --ignore glibc
> 
> OK.
> 
> > pacman -S --force filesystem --ignore glibc
> 
> OK.
> 
> > pacman -Sd 
> 
> OK. FWIW, the list of packages was:
> 
> attica  binutils  boost-libs  eclipse  eclipse-cdt  faac  ffmpeg  gcc
> gcc-libs  gnutls  grep  gstreamer0.10-bad-plugins  icu  jedit  kdebase-runtime
>  kdelibs  libcups  libgl  liblrdf  libmp4v2  libproxy  libtool  libva  linux
> mesa mkinitcpio  openjdk6  pcre  poppler  poppler-glib  qt  raptor  soprano
> swig  xine-lib  xorg-server-xephyr
> 
> > pacman -Su
> > 
> 
> Not OK:
> 
> > [root@shack n7dr]# pacman -Su
> > :: Starting full system upgrade...
> > resolving dependencies...
> > looking for inter-conflicts...
> > 
> > Targets (1): glibc-2.16.0-2
> > 
> > Total Installed Size:   33.94 MiB
> > Net Upgrade Size:   0.83 MiB
> > 
> > Proceed with installation? [Y/n] 
> > (1/1) checking package integrity
> >   
> > [##]
> >  100%
> > (1/1) loading package files 
> >   
> > [##]
> >  100%
> > (1/1) checking for file conflicts   
> >   
> > [##]
> >  100%
> > error: failed to commit transaction (conflicting files)
> > glibc: /lib exists in filesystem
> > Errors occurred, no packages were upgraded.

I got the same error at that point.  What this means is that you either have
some unowned (by any package) files in /lib (/lib/modules/* is a good candidate)
or you have some other packages (most likely from AUR) owning files under /lib.
The wiki page explains well how to look for them.  At least, I followed those
instructions and managed to identify the packages that blocked the upgrade.  The
key here really seems to be to make sure that glibc is the only package which at
this point owns anything under /lib.  I think in my case it also helped to
uninstall some packages and reinstall them after the glibc upgrade.  Keep
pushing, you're almost there ;)

Cheers,
Norbert

Re: [arch-general] Still Glibc problems

[Baho Utot]

On 07/20/2012 12:46 PM, Tom Gundersen wrote:

On Jul 20, 2012 6:08 PM, "Baho Utot"  wrote:

On 07/20/2012 10:47 AM, Tom Gundersen wrote:

On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans  wrote:

There's nothing on this system that hasn't come from either AUR or the
official arch repositories, so I don't know why I'm having any problems

at all :-(

I have seen people having problems because they installed packages
from repos that they no longer have active (typically multilib), make
sure to either remove any "stale" packages or re-enable any repos so
you get all the most recent updates.


I had a desktop system hosed that only packages in core, extra and

community installed.

I never heard of anyone actually hosing their system without using --force.
What happened? (I'm assuming you don't use testing?).

-t


No I didn't use testing.
Followed the news release..rebootedsystem borked.

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Norbert Zeh said the following at 07/19/2012 06:08 PM :

> 
> Well, the filesystem instructions are older and applied at the time the glibc
> upgrade was not an issue yet.  Combining the two instructions, I would guess 
> the
> following should work:
> 
> pacman -Syu --ignore filesystem --ignore glibc

OK.

> pacman -S --force filesystem --ignore glibc

OK.

> pacman -Sd 

OK. FWIW, the list of packages was:

attica  binutils  boost-libs  eclipse  eclipse-cdt  faac  ffmpeg  gcc
gcc-libs  gnutls  grep  gstreamer0.10-bad-plugins  icu  jedit  kdebase-runtime
 kdelibs  libcups  libgl  liblrdf  libmp4v2  libproxy  libtool  libva  linux
mesa mkinitcpio  openjdk6  pcre  poppler  poppler-glib  qt  raptor  soprano
swig  xine-lib  xorg-server-xephyr

> pacman -Su
> 

Not OK:

> [root@shack n7dr]# pacman -Su
> :: Starting full system upgrade...
> resolving dependencies...
> looking for inter-conflicts...
> 
> Targets (1): glibc-2.16.0-2
> 
> Total Installed Size:   33.94 MiB
> Net Upgrade Size:   0.83 MiB
> 
> Proceed with installation? [Y/n] 
> (1/1) checking package integrity  
> 
> [##]
>  100%
> (1/1) loading package files   
> 
> [##]
>  100%
> (1/1) checking for file conflicts 
> 
> [##]
>  100%
> error: failed to commit transaction (conflicting files)
> glibc: /lib exists in filesystem
> Errors occurred, no packages were upgraded.
> [root@shack n7dr]# 

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Tom Gundersen said the following at 07/20/2012 02:41 PM :
> On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans  wrote:
>> Norbert Zeh said the following at 07/20/2012 12:27 PM :
>>
>>> think the reason why you are having a much more serious issue is that it 
>>> seems
>>> you haven't updated your system in a long time.  So now you're running into
>>
>> Approximately a month, I believe. Certainly not a whole lot longer. I don't
>> regard that as a long time, but perhaps in the arch world it is. But since 
>> the
>> box I'm upgrading often goes a couple of months without even being powered 
>> up,
>> it would be hard to upgrade more frequently.
> 
> No, a month is not a long time. I would have thought more than half a
> year (which is still not awfully long, but would mean you would be hit

Definitely nothing even close to that.

I do note that, as I mentioned, /var/run and /var/lock were symlinks, which I
think is a change from about six months ago.

I'm about to try the suggested sequence:

> pacman -Syu --ignore filesystem --ignore glibc
> pacman -S --force filesystem --ignore glibc
> pacman -Sd 
> pacman -Su

and we'll see what happens.

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans  wrote:
> Norbert Zeh said the following at 07/20/2012 12:27 PM :
>
>> think the reason why you are having a much more serious issue is that it 
>> seems
>> you haven't updated your system in a long time.  So now you're running into
>
> Approximately a month, I believe. Certainly not a whole lot longer. I don't
> regard that as a long time, but perhaps in the arch world it is. But since the
> box I'm upgrading often goes a couple of months without even being powered up,
> it would be hard to upgrade more frequently.

No, a month is not a long time. I would have thought more than half a
year (which is still not awfully long, but would mean you would be hit
by the problem explained in
http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/).
Anyway, I didn't mean to imply that you have to update at a certain
frequency, just to offer a possible explanation why you are seeing
problems that relatively few other people are seeing.

-t

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Norbert Zeh said the following at 07/20/2012 12:27 PM :

> think the reason why you are having a much more serious issue is that it seems
> you haven't updated your system in a long time.  So now you're running into

Approximately a month, I believe. Certainly not a whole lot longer. I don't
regard that as a long time, but perhaps in the arch world it is. But since the
box I'm upgrading often goes a couple of months without even being powered up,
it would be hard to upgrade more frequently.

Maybe I made a mistake putting arch on it, if arch really does have to be
upgraded more frequently than that. I was unaware that that was a
consideration. I've never used a "rolling release" distribution before, and
perhaps I shouldn't have done so on the machine in question. I (naïfly)
thought that the package manager system would automagically take care of
everything regardless of how many updates needed to be applied.

Computers... even after all this time, still a learning experience. Even when
I don't want them to be.

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/12 07:47, Tom Gundersen wrote:
> On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans 
> wrote:
>> There's nothing on this system that hasn't come from either AUR
>> or the official arch repositories, so I don't know why I'm having
>> any problems at all :-(
> 
> I have seen people having problems because they installed packages 
> from repos that they no longer have active (typically multilib),
> make sure to either remove any "stale" packages or re-enable any
> repos so you get all the most recent updates.
> 
This is one thing I found I had to do. It's certainly fast enough. I
just removed these packages prior to the upgrade and reinstalled them
afterwards. Once the sym-link for /lib is in place, everything lands
in the right place.

- -- 
David Benfell
benf...@parts-unknown.org


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQCb36AAoJELT202JKF+xpe9MQAJatGuaBy5xCXeeTsxJTisZp
uUQQNxrlj7ChsNgSLn97ebdZUBCYNsBwKvYQYrpOaR7mct/Wnco7NmzflH5QgWb5
D2mG4UQFhALEXeSLdSn09+Cfl/T1FJTiBmUHdwuTC1s3GykKX4r/ev9VhC9FBqXL
mttQJfoNiq73CasWz1L9LcRzXwD4HCkH/Cnf5arxGFMcJfVyVVzzq9Z1V8ZKXh78
qYl2+uI6ZAis9/QB9b1JDjUnTdJbcNMOMXTmhdgh+MqmE6lNADflRgMwyTm8xoIG
9e3/ljNsya+SarAnanC8f8B7Xb+wpN+UymM6OE4FXc50S9R8LeAvb7RyM9WaqP7k
rBOelqmqzIeM/yqInUKm9aVxmic7OMNpv88Nzh02LTpFPWM9dQkRXGRvxIYuHAJM
U3r7po6CyW6yR3wG3ErOojGJ22Bq989f7QVSRYjGyDPUmIYfn8ijd5TxZgtotft3
k3Z50CWt4Ww1psGmEJyP6ZXFFH6rT9j3IPhqh6cmaQYmHsQm7MQx5t6lDV7eB/BA
wuA45uTcbuH4+AChBy50yoEy+8bkco59v0qVPOpKMubFL8qXELnVhSUaRwvcs5C9
jAu80fFO3l8/oE5z+ZqkSEzRiy0sxxHphfvPBjEAWM2PpQBSrzTA9BS4EyTJiF2q
MlyA6npY9x5Uz8SwQK5O
=WaCS
-END PGP SIGNATURE-

Re: [arch-general] Still Glibc problems

[Norbert Zeh]

D. R. Evans [2012.07.20 0827 -0600]:
> Norbert Zeh said the following at 07/19/2012 06:08 PM :
> 
> > 
> > Well, the filesystem instructions are older and applied at the time the 
> > glibc
> > upgrade was not an issue yet.  Combining the two instructions, I would 
> > guess the
> > following should work:
> > 
> > pacman -Syu --ignore filesystem --ignore glibc
> > pacman -S --force filesystem --ignore glibc
> > pacman -Sd 
> 
> Incidentally, this is quite a long list.
> https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest
> that the list will contain only a few items, but the actual number is of the
> order a couple of dozen packages.
> 
> > pacman -Su
> > 
> > Note that I did not try this, but it seems to be the logical combination of 
> > the
> > two.  Maybe one of the developers can chime in and confirm that this is the
> > right strategy.
> 
> I am rather reticent to try something untested, especially when I see the
> --force option in use. So yes, PLEASE, can a developer address this issue so
> that I can have more confidence that I won't end up with a hosed system.
> 
> (I am very puzzled as to why this is happening at all. This is not a system to
> which anything fancy has ever been done. If I'm having this problem, I don't
> know why lots of others aren't seeing it too.)

I got a fairly long list of packages I had to ignore in the first run, too, and
I had a few unowned files in /lib I had to clean out.  It all worked very well
following the instructions on the wiki, though.  So no complaints at all.  I
think the reason why you are having a much more serious issue is that it seems
you haven't updated your system in a long time.  So now you're running into
dealing with two slightly tricky upgrades (filesystem + glibc) at the same time.
I upgrade packages very frequently.  So I dealt with the filesystem upgrade a
few weeks ago, and all went smoothly.  Having an up-to-date filesystem package,
the upgrade of glibc was also fairly straightforward, even if it involved quite
a bit of manual intervention.

I think the lesson to be learned here is that not upgrading packages on an arch
box for a long time is not the best idea, and I think most arch users do upgrade
quite frequently.

Cheers,
Norbert

Re: [arch-general] Still Glibc problems

[Guus Snijders]

Op 20 jul. 2012 16:21 schreef "D. R. Evans"  het
volgende:
>
> Guus Snijders said the following at 07/20/2012 04:13 AM :
[...]

> > If i understand correctly, the symlinks for /var/run and /var/lock are
> > there already.
>
> Yes.
>
> >
> > If fileystem is not yet upgraded, what might just work is to restore
>
> I don't know what you mean by "the filesystem is not yet upgraded".

My apologies, i meant the package filesystem there.

I understand now that in your current situation a forced install of the
package filesystem would be safe.

I guess it would be wise to wait with the glibc package until everything
else is updated and the box rebooted (just to be sure).
I'm not a big fan of rebooting, but in this case ;-)

Hope that helpes.

Mvg, Guus

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Jul 20, 2012 6:08 PM, "Baho Utot"  wrote:
>
> On 07/20/2012 10:47 AM, Tom Gundersen wrote:
>>
>> On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans  wrote:
>>>
>>> There's nothing on this system that hasn't come from either AUR or the
>>> official arch repositories, so I don't know why I'm having any problems
at all :-(
>>
>> I have seen people having problems because they installed packages
>> from repos that they no longer have active (typically multilib), make
>> sure to either remove any "stale" packages or re-enable any repos so
>> you get all the most recent updates.
>
>
> I had a desktop system hosed that only packages in core, extra and
community installed.

I never heard of anyone actually hosing their system without using --force.
What happened? (I'm assuming you don't use testing?).

-t

Re: [arch-general] Still Glibc problems

[Baho Utot]

On 07/20/2012 10:47 AM, Tom Gundersen wrote:

On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans  wrote:

There's nothing on this system that hasn't come from either AUR or the
official arch repositories, so I don't know why I'm having any problems at all 
:-(

I have seen people having problems because they installed packages
from repos that they no longer have active (typically multilib), make
sure to either remove any "stale" packages or re-enable any repos so
you get all the most recent updates.


I had a desktop system hosed that only packages in core, extra and 
community installed.

Re: [arch-general] Still Glibc problems

[Baho Utot]

On 07/20/2012 10:27 AM, D. R. Evans wrote:

Norbert Zeh said the following at 07/19/2012 06:08 PM :


Well, the filesystem instructions are older and applied at the time the glibc
upgrade was not an issue yet.  Combining the two instructions, I would guess the
following should work:

pacman -Syu --ignore filesystem --ignore glibc
pacman -S --force filesystem --ignore glibc
pacman -Sd 

Incidentally, this is quite a long list.
https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest
that the list will contain only a few items, but the actual number is of the
order a couple of dozen packages.


pacman -Su

Note that I did not try this, but it seems to be the logical combination of the
two.  Maybe one of the developers can chime in and confirm that this is the
right strategy.

I am rather reticent to try something untested, especially when I see the
--force option in use. So yes, PLEASE, can a developer address this issue so
that I can have more confidence that I won't end up with a hosed system.

(I am very puzzled as to why this is happening at all. This is not a system to
which anything fancy has ever been done. If I'm having this problem, I don't
know why lots of others aren't seeing it too.)

   Doc



I had this problem on the few remaining arch desktop boxes that I admin.

I fixed those by installing Fedora 17, the server boxes were "fixed" by 
my own distro...LFS and pacman-3.3.3 as the package manager.

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Fri, Jul 20, 2012 at 4:27 PM, D. R. Evans  wrote:
> Norbert Zeh said the following at 07/19/2012 06:08 PM :
>
>>
>> Well, the filesystem instructions are older and applied at the time the glibc
>> upgrade was not an issue yet.  Combining the two instructions, I would guess 
>> the
>> following should work:
>>
>> pacman -Syu --ignore filesystem --ignore glibc [and ignore any other 
>> packages that block the upgrade]
>> pacman -S --force filesystem --ignore glibc
>> pacman -Sd 

Looks good to me.

> Incidentally, this is quite a long list.
> https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest
> that the list will contain only a few items, but the actual number is of the
> order a couple of dozen packages.

That's surprising that it is so many, however, it appears you haven't
updated this system in some time which might explain that it is
different to what most people are seeing.

-t

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans  wrote:
> There's nothing on this system that hasn't come from either AUR or the
> official arch repositories, so I don't know why I'm having any problems at 
> all :-(

I have seen people having problems because they installed packages
from repos that they no longer have active (typically multilib), make
sure to either remove any "stale" packages or re-enable any repos so
you get all the most recent updates.

Lastly, AUR is user-maintained so could contain anything at all (i.e.
it is not surprising that they are causing problems). I'd suggest just
removing all packages from the AUR for the time being, and once the
update has succeeded you can reinstall them.

-t

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Fri, Jul 20, 2012 at 12:13 PM, Guus Snijders  wrote:
> I'm a bit confused at this point if filesystem is now upgraded or not.
> If i understand correctly, the symlinks for /var/run and /var/lock are
> there already.

You should always have the symlink, regardless of whether or not
filesystem is up-to-date (read the news item again, it is explained
there). The difference is that with the new filesystem package, the
symlinks are owned by the package as they should be, rather than not
having any owner at all.

To check if your pacakge is up-to-date, you can simply do "pacman -Qi
filesystem" and it will tell you.

> If fileystem is not yet upgraded, what might just work is to restore
> the previous state:
> delete /var/run and /var/lock (the symlinks), re-create them as
> directories and then install filesystem again.
> That way the situation is exactly as filesystem expects and the
> upgrade should go smoothly without --force.

This seems wrong. Please re-read the filesystem news announcement.
There should never be any reason to replace the symlinks by
directories, that will not help at all. Notice that if you are in the
situation that you have to force a filesystem upgrade, make sure you
force only that, and nothing else (in particular not glibc).

> I /think/ the same goes for glibc, although i'm not sure about that one.
> If /lib is already a symlink but the package doesn't install, the
> safest procedure would appear to be something like:
> - boot from livecd
> - mount the local filesystems
> - delete the /lib symlink and create the /lib directory
> - use pacmans's --root parameter to update glibc

No point in creating a /lib directory. If you are booting from a
live-cd, all you should have to do is: uninstall all pacakges that
cause file-conflicts; delete (or move out of the way) all files that
are not owned by any packages and cause file conflicts; install glibc;
and finally reinstall whatever packages you had to remove (though if
you had to remove them that probably means that there is something
wrong with them, all official packages have been updated to not need
removing).

> Both are untested, though.

I suggest to anyone who still have problems, to first try the guide on
the wiki, if that does not work, find one of the guides on the forum
(but first check that other commenters are confirming that they are
correct).

-t

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Norbert Zeh said the following at 07/19/2012 06:08 PM :

> 
> Well, the filesystem instructions are older and applied at the time the glibc
> upgrade was not an issue yet.  Combining the two instructions, I would guess 
> the
> following should work:
> 
> pacman -Syu --ignore filesystem --ignore glibc
> pacman -S --force filesystem --ignore glibc
> pacman -Sd 

Incidentally, this is quite a long list.
https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest
that the list will contain only a few items, but the actual number is of the
order a couple of dozen packages.

> pacman -Su
> 
> Note that I did not try this, but it seems to be the logical combination of 
> the
> two.  Maybe one of the developers can chime in and confirm that this is the
> right strategy.

I am rather reticent to try something untested, especially when I see the
--force option in use. So yes, PLEASE, can a developer address this issue so
that I can have more confidence that I won't end up with a hosed system.

(I am very puzzled as to why this is happening at all. This is not a system to
which anything fancy has ever been done. If I'm having this problem, I don't
know why lots of others aren't seeing it too.)

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Guus Snijders said the following at 07/20/2012 04:13 AM :

> 
> I'm a bit confused at this point if filesystem is now upgraded or not.

Your confusion can't possibly be as great as mine :-)

There's nothing on this system that hasn't come from either AUR or the
official arch repositories, so I don't know why I'm having any problems at all 
:-(

> If i understand correctly, the symlinks for /var/run and /var/lock are
> there already.

Yes.

> 
> If fileystem is not yet upgraded, what might just work is to restore

I don't know what you mean by "the filesystem is not yet upgraded".

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[Guus Snijders]

2012/7/20 David Benfell :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/19/12 16:42, D. R. Evans wrote:
>>
>> pacman -Syu --ignore filesystem && pacman -S filesystem --force
>>
>> 
>>
>> and that gives:
>>
>> 
>>
>> error: failed to commit transaction (conflicting files) glibc: /lib
>> exists in filesystem Errors occurred, no packages were upgraded.
>>
>> 
>>
> Somebody will need to clarify the precise syntax. But it looks to me
> like you can't just ignore filesystem here; you also need to ignore
> glibc, then--I think--do the glibc upgrade without the --force option
> following the filesystem upgrade.

I'm a bit confused at this point if filesystem is now upgraded or not.
If i understand correctly, the symlinks for /var/run and /var/lock are
there already.

If fileystem is not yet upgraded, what might just work is to restore
the previous state:
delete /var/run and /var/lock (the symlinks), re-create them as
directories and then install filesystem again.
That way the situation is exactly as filesystem expects and the
upgrade should go smoothly without --force.

I /think/ the same goes for glibc, although i'm not sure about that one.
If /lib is already a symlink but the package doesn't install, the
safest procedure would appear to be something like:
- boot from livecd
- mount the local filesystems
- delete the /lib symlink and create the /lib directory
- use pacmans's --root parameter to update glibc

Both are untested, though.
On the bright side, i know from experience that it's fairly simple to
completely reinstall Arch (had a bad HDD once).


mvg,
Guus

Re: [arch-general] Still Glibc problems

[Norbert Zeh]

D. R. Evans [2012.07.19 1742 -0600]:
> Alex Belanger said the following at 07/18/2012 05:27 AM :
> > pacman -Syu --ignore glibc pacman -Su
> 
> > I had the same problem, went to archlinux website and they say exactly what
> > you need to do and why. You shouldn't toy with it yourself, nor use the
> > --force option. Try this, if it doesn't work, they have an in-depth guide
> > too.
> > 
> 
> I have tried this, and there seems to be a catch-22...
> 
> 1. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib
> 
> 
> 
> If running "pacman -Syu --ignore glibc" gives:
> 
> warning: ignoring package glibc-2.16.0-2
> warning: cannot resolve "glibc>=2.16", a dependency of "gcc-libs"
> 
> ...
> 
> :: The following packages cannot be upgraded due to unresolvable dependencies:
>  binutils  gcc  gcc-libs
> 
> Do you want to skip the above packages for this upgrade [y/N]
> 
> Say "y" to skipping the packages, then install them all using (e.g.):
> 
> 
> 
> But if I do that, I hit the /var/run and /var/lock problem:
> 
> 
> 
> (127/127) checking for file conflicts
> 
> [##]
> 100%
> error: failed to commit transaction (conflicting files)
> filesystem: /var/lock exists in filesystem
> filesystem: /var/run exists in filesystem
> Errors occurred, no packages were upgraded.
> [root@shack n7dr]#
> 
> 
> 
> 2.
> https://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/
> 
> So instead of dealing with glibc, I try to deal with the /var/run and
> /var/lock problem first. On my system, these are both symlinks. So, following
> instructions, I do:
> 
> 
> 
> If the symlinks are already in place on your system (which should be the case
> for most people), then you can simply perform
> 
> pacman -Syu --ignore filesystem && pacman -S filesystem --force
> 
> 
> 
> and that gives:
> 
> 
> 
> error: failed to commit transaction (conflicting files)
> glibc: /lib exists in filesystem
> Errors occurred, no packages were upgraded.
> 
> 
> 
> So it looks to me that I'm being told, basically, "you have two errors, α and
> β. Before you fix α you must fix β. And before you fix β you must fix α."
> 
> Am I misinterpreting or misunderstanding the instructions? They seem pretty
> clear, and I believe I followed them faithfully.
> 
>   Doc
> 
> -- 
> Web:  http://www.sff.net/people/N7DR
> 

Well, the filesystem instructions are older and applied at the time the glibc
upgrade was not an issue yet.  Combining the two instructions, I would guess the
following should work:

pacman -Syu --ignore filesystem --ignore glibc
pacman -S --force filesystem --ignore glibc
pacman -Sd 
pacman -Su

Note that I did not try this, but it seems to be the logical combination of the
two.  Maybe one of the developers can chime in and confirm that this is the
right strategy.

Cheers,
Norbert

Re: [arch-general] Still Glibc problems

[David Benfell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/19/12 16:42, D. R. Evans wrote:
> 
> pacman -Syu --ignore filesystem && pacman -S filesystem --force
> 
> 
> 
> and that gives:
> 
> 
> 
> error: failed to commit transaction (conflicting files) glibc: /lib
> exists in filesystem Errors occurred, no packages were upgraded.
> 
> 
> 
Somebody will need to clarify the precise syntax. But it looks to me
like you can't just ignore filesystem here; you also need to ignore
glibc, then--I think--do the glibc upgrade without the --force option
following the filesystem upgrade.

- -- 
David Benfell
benf...@parts-unknown.org


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQCKEMAAoJELT202JKF+xpyyIP/jWg2DW+0+XiJUQV9E+xVKRE
gPHw3t1X/AUhG6Xijtu9ApfjiUlSQg44Zk9uJoGjhGdb/a/SqdROUzvnoHc7A7/3
FI32L+fQTyJJb84f1V93MeC/T1hyC3Pjht8xHOjIoDcgf1LmlWsy0gnXothJFagV
h0hYrQ8nQbtmib1GHKlGyfMdRReL9+dZKm9p3n4G29rkvTzCEfG/S52/lgvCyoQZ
gmJ2rJq4h2IQpIHIN6sSKJc8GlgYJMyYGuxTxi/XztBFUtl9mzhNvrmMILVPAvC9
qkuiF1fuZv7322jPfI6F3eBmvttrFS6SJMpRnK6D1oAS06pPWrksSul6O4ckguTM
jNWwxS4oz1+1KhwcRrGx7jr3Df+/eVTYMREPBkjqEAyt1s2rtH7R9Yx08nB2Lfd5
1dnLYSDyFI7H5zmR6xbnq2+Bz9oSkpUCIK3Wn4Li0Z0SgW4dinzisO59AQKG64hS
/3SSOzQxvcsMnIExL3D1uOh5Wu5ibew9IKd9wEfKsyq9iFsLBnHtlCx/lc93keb1
CpHUuEpyD+dRzB95iHqwr3pKgK5iFDuyehZTYvnyWNtieaJt53Yl3S67phc9jBzr
rwh8w0NYWD870vvJnu239L4ZxwkaUru5KAiJE+iDN/o3fKbjorLkxmq0komhTq4x
Rj8HqUOr2tCDulVG8gdV
=v+z4
-END PGP SIGNATURE-

Re: [arch-general] Still Glibc problems

[D. R. Evans]

Alex Belanger said the following at 07/18/2012 05:27 AM :
> pacman -Syu --ignore glibc pacman -Su

> I had the same problem, went to archlinux website and they say exactly what
> you need to do and why. You shouldn't toy with it yourself, nor use the
> --force option. Try this, if it doesn't work, they have an in-depth guide
> too.
> 

I have tried this, and there seems to be a catch-22...

1. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib



If running "pacman -Syu --ignore glibc" gives:

warning: ignoring package glibc-2.16.0-2
warning: cannot resolve "glibc>=2.16", a dependency of "gcc-libs"

...

:: The following packages cannot be upgraded due to unresolvable dependencies:
 binutils  gcc  gcc-libs

Do you want to skip the above packages for this upgrade [y/N]

Say "y" to skipping the packages, then install them all using (e.g.):



But if I do that, I hit the /var/run and /var/lock problem:



(127/127) checking for file conflicts

[##]
100%
error: failed to commit transaction (conflicting files)
filesystem: /var/lock exists in filesystem
filesystem: /var/run exists in filesystem
Errors occurred, no packages were upgraded.
[root@shack n7dr]#



2.
https://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/

So instead of dealing with glibc, I try to deal with the /var/run and
/var/lock problem first. On my system, these are both symlinks. So, following
instructions, I do:



If the symlinks are already in place on your system (which should be the case
for most people), then you can simply perform

pacman -Syu --ignore filesystem && pacman -S filesystem --force



and that gives:



error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
Errors occurred, no packages were upgraded.



So it looks to me that I'm being told, basically, "you have two errors, α and
β. Before you fix α you must fix β. And before you fix β you must fix α."

Am I misinterpreting or misunderstanding the instructions? They seem pretty
clear, and I believe I followed them faithfully.

  Doc

-- 
Web:  http://www.sff.net/people/N7DR



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Still Glibc problems

[André Gasser]

Hello all,

I also experienced initial problems getting the new glibc 2.16.0-2 to
work. In my case, the problem was an older version of lib32-glibc (I
think I had version 2.14.x installed, sorry can't remember exactly).
After enabling the multilib repo in /etc/pacman.conf and doing

sudo pacman -Syu --ignore glibc
sudo pacman -Su

Here is a link to a corresponding forum post:
https://bbs.archlinux.org/viewtopic.php?pid=1131545

Everything was updated well.

HTH,
André


On 07/18/2012 11:10 PM, P .NIKOLIC wrote:
> On Wed, 18 Jul 2012 12:27:11 +0200
> Tom Gundersen  wrote:
> 
> Pruned
>>
>> You sholud delete the duplicate files from /usr/lib, did you do this?
>> Then it _should_ work...
>>
>> -t
> 
> 
> Hi Tom 
> 
> 
> Well word on the street is it seems to have worked at last
> now i have another problem cropped up for which i will start a new
> thread
> 
> ThanksPete .
> 

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Wed, 18 Jul 2012 12:27:11 +0200
Tom Gundersen  wrote:

Pruned
> 
> You sholud delete the duplicate files from /usr/lib, did you do this?
> Then it _should_ work...
> 
> -t


Hi Tom 


Well word on the street is it seems to have worked at last
now i have another problem cropped up for which i will start a new
thread

ThanksPete .

-- 
Linux 7-of-9 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Wed, 18 Jul 2012 12:27:11 +0200
Tom Gundersen  wrote:

Pruned
> 
> You sholud delete the duplicate files from /usr/lib, did you do this?
> Then it _should_ work...
> 
> -t

Hi Tom

Ok i will give it a whirl see what transpires


CheersPete
 

-- 
Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Wed, 18 Jul 2012 07:27:57 -0400
Alex Belanger  wrote:

> pacman -Syu --ignore glibc
> pacman -Su
> I had the same problem, went to archlinux website and they say
> exactly what you need to do and why. You shouldn't toy with it
> yourself, nor use the --force option. Try this, if it doesn't work,
> they have an in-depth guide too.
> 
> Otherwise I cannot stress out more the importance of reading the
> announcements whenever you're upgrading.
> 
>

Been there done that still fails ...else i would not be trying to solve
the problem here ..


Pete

-- 
Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[Alex Belanger]

pacman -Syu --ignore glibc
pacman -Su
I had the same problem, went to archlinux website and they say exactly what you 
need to do and why. You shouldn't toy with it yourself, nor use the --force 
option. Try this, if it doesn't work, they have an in-depth guide too.

Otherwise I cannot stress out more the importance of reading the announcements 
whenever you're upgrading.

On Jul 18, 2012, at 6:27 AM, Tom Gundersen  wrote:

> On Wed, Jul 18, 2012 at 12:24 PM, P .NIKOLIC  
> wrote:
>> On Wed, 18 Jul 2012 09:22:53 +0200
>> Tom Gundersen  wrote:
>> 
>>> On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC
>>>  wrote:
 On Wed, 18 Jul 2012 00:46:49 +0200
 Tom Gundersen  wrote:
 
> On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC
>  wrote:
>> Right after much faffing about  i now have the box back to
> 
> So if /lib is NOT a symlink, then all you should need is to delete
> all the files in /usr/lib that are not owned by any package. Then
> you should be able to upgrade.
 
 Hi .
 
 Right i have sort of put a list together but well  see below ..
>>> 
>>> You just have to delete the files that show up as being in conflict
>>> when you try to upgrade. Just make sure that 1) /lib is not a symlink
>>> and 2) those files are not owned by any other package.
>>> 
>>> -t
>> 
>> Hu  ..
>> 
>> No matter what it try  it still boils down to this list of errors
>> 
>> error: failed to commit transaction (conflicting files)
>> glibc: /usr/lib/ld-2.16.so exists in filesystem
>> glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem
>> glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
>> glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
>> glibc: /usr/lib/libSegFault.so exists in filesystem
>> glibc: /usr/lib/libanl-2.16.so exists in filesystem
>> glibc: /usr/lib/libanl.so.1 exists in filesystem
>> glibc: /usr/lib/libc-2.16.so exists in filesystem
>> glibc: /usr/lib/libc.so.6 exists in filesystem
>> glibc: /usr/lib/libcidn-2.16.so exists in filesystem
>> glibc: /usr/lib/libcidn.so.1 exists in filesystem
>> glibc: /usr/lib/libcrypt-2.16.so exists in filesystem
>> glibc: /usr/lib/libcrypt.so.1 exists in filesystem
>> glibc: /usr/lib/libdl-2.16.so exists in filesystem
>> glibc: /usr/lib/libdl.so.2 exists in filesystem
>> glibc: /usr/lib/libm-2.16.so exists in filesystem
>> glibc: /usr/lib/libm.so.6 exists in filesystem
>> glibc: /usr/lib/libmemusage.so exists in filesystem
>> glibc: /usr/lib/libnsl-2.16.so exists in filesystem
>> glibc: /usr/lib/libnsl.so.1 exists in filesystem
>> glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
>> glibc: /usr/lib/libnss_db-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_db.so.2 exists in filesystem
>> glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
>> glibc: /usr/lib/libnss_files-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_files.so.2 exists in filesystem
>> glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
>> glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
>> glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem
>> glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
>> glibc: /usr/lib/libpcprofile.so exists in filesystem
>> glibc: /usr/lib/libpthread-2.16.so exists in filesystem
>> glibc: /usr/lib/libpthread.so.0 exists in filesystem
>> glibc: /usr/lib/libresolv-2.16.so exists in filesystem
>> glibc: /usr/lib/libresolv.so.2 exists in filesystem
>> glibc: /usr/lib/librt-2.16.so exists in filesystem
>> glibc: /usr/lib/librt.so.1 exists in filesystem
>> glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
>> glibc: /usr/lib/libthread_db.so.1 exists in filesystem
>> glibc: /usr/lib/libutil-2.16.so exists in filesystem
>> glibc: /usr/lib/libutil.so.1 exists in filesystem
>> Errors occurred, no packages were upgraded.
>> 
>> 
>> lib is NOT a symlink
>> 
>> pacman -Qo /lib/*
>> /lib/ld-2.16.so is owned by glibc 2.16.0-1
>> /lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
>> /lib/libanl-2.16.so is owned by glibc 2.16.0-1
>> /lib/libanl.so.1 is owned by glibc 2.16.0-1
>> /lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
>> /lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
>> /lib/libc-2.16.so is owned by glibc 2.16.0-1
>> /lib/libcidn-2.16.so is owned by glibc 2.16.0-1
>> /lib/libcidn.so.1 is owned by glibc 2.16.0-1
>> /lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
>> /lib/libcrypt.so.1 is owned by glibc 2.16.0-1
>> /lib/libc.so.6 is owned by glibc 2.16.0-1
>> /lib/libdl-2.16.so is owned by glibc 2.16.0-1
>> /lib/libdl.so.2 is owned by glibc 2.16.0-1
>> /lib/libm-2.16.so is owned by glibc 2.16.0-1
>> /lib/libmemusage.so is owned by glibc 2.16.0-1
>> /lib/libm.so.6 is owned by glibc 2.16.0-1
>> /lib/libnsl-2.16.so is owned by gli

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Wed, Jul 18, 2012 at 12:24 PM, P .NIKOLIC  wrote:
> On Wed, 18 Jul 2012 09:22:53 +0200
> Tom Gundersen  wrote:
>
>> On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC
>>  wrote:
>> > On Wed, 18 Jul 2012 00:46:49 +0200
>> > Tom Gundersen  wrote:
>> >
>> >> On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC
>> >>  wrote:
>> >> > Right after much faffing about  i now have the box back to
>> >>
>> >> So if /lib is NOT a symlink, then all you should need is to delete
>> >> all the files in /usr/lib that are not owned by any package. Then
>> >> you should be able to upgrade.
>> >
>> > Hi .
>> >
>> > Right i have sort of put a list together but well  see below ..
>>
>> You just have to delete the files that show up as being in conflict
>> when you try to upgrade. Just make sure that 1) /lib is not a symlink
>> and 2) those files are not owned by any other package.
>>
>> -t
>
> Hu  ..
>
> No matter what it try  it still boils down to this list of errors
>
> error: failed to commit transaction (conflicting files)
> glibc: /usr/lib/ld-2.16.so exists in filesystem
> glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem
> glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
> glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
> glibc: /usr/lib/libSegFault.so exists in filesystem
> glibc: /usr/lib/libanl-2.16.so exists in filesystem
> glibc: /usr/lib/libanl.so.1 exists in filesystem
> glibc: /usr/lib/libc-2.16.so exists in filesystem
> glibc: /usr/lib/libc.so.6 exists in filesystem
> glibc: /usr/lib/libcidn-2.16.so exists in filesystem
> glibc: /usr/lib/libcidn.so.1 exists in filesystem
> glibc: /usr/lib/libcrypt-2.16.so exists in filesystem
> glibc: /usr/lib/libcrypt.so.1 exists in filesystem
> glibc: /usr/lib/libdl-2.16.so exists in filesystem
> glibc: /usr/lib/libdl.so.2 exists in filesystem
> glibc: /usr/lib/libm-2.16.so exists in filesystem
> glibc: /usr/lib/libm.so.6 exists in filesystem
> glibc: /usr/lib/libmemusage.so exists in filesystem
> glibc: /usr/lib/libnsl-2.16.so exists in filesystem
> glibc: /usr/lib/libnsl.so.1 exists in filesystem
> glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
> glibc: /usr/lib/libnss_db-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_db.so.2 exists in filesystem
> glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
> glibc: /usr/lib/libnss_files-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_files.so.2 exists in filesystem
> glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
> glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
> glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
> glibc: /usr/lib/libpcprofile.so exists in filesystem
> glibc: /usr/lib/libpthread-2.16.so exists in filesystem
> glibc: /usr/lib/libpthread.so.0 exists in filesystem
> glibc: /usr/lib/libresolv-2.16.so exists in filesystem
> glibc: /usr/lib/libresolv.so.2 exists in filesystem
> glibc: /usr/lib/librt-2.16.so exists in filesystem
> glibc: /usr/lib/librt.so.1 exists in filesystem
> glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
> glibc: /usr/lib/libthread_db.so.1 exists in filesystem
> glibc: /usr/lib/libutil-2.16.so exists in filesystem
> glibc: /usr/lib/libutil.so.1 exists in filesystem
> Errors occurred, no packages were upgraded.
>
>
> lib is NOT a symlink
>
>  pacman -Qo /lib/*
> /lib/ld-2.16.so is owned by glibc 2.16.0-1
> /lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
> /lib/libanl-2.16.so is owned by glibc 2.16.0-1
> /lib/libanl.so.1 is owned by glibc 2.16.0-1
> /lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
> /lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
> /lib/libc-2.16.so is owned by glibc 2.16.0-1
> /lib/libcidn-2.16.so is owned by glibc 2.16.0-1
> /lib/libcidn.so.1 is owned by glibc 2.16.0-1
> /lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
> /lib/libcrypt.so.1 is owned by glibc 2.16.0-1
> /lib/libc.so.6 is owned by glibc 2.16.0-1
> /lib/libdl-2.16.so is owned by glibc 2.16.0-1
> /lib/libdl.so.2 is owned by glibc 2.16.0-1
> /lib/libm-2.16.so is owned by glibc 2.16.0-1
> /lib/libmemusage.so is owned by glibc 2.16.0-1
> /lib/libm.so.6 is owned by glibc 2.16.0-1
> /lib/libnsl-2.16.so is owned by glibc 2.16.0-1
> /lib/libnsl.so.1 is owned by glibc 2.16.0-1
> /lib/libnss_compat-2.16.so is owned by glibc 2.16.0-1
> /lib/libnss_compat.so.2 is owned by glibc 2.16.0-1
> /lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
> /lib/libnss_db.so.2 is owned by glibc 2.16.0-1
> /lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
> /lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
> /lib/libnss_files-2.16.so is owned by glibc 2.16.0-1
> /lib/libnss_files.so.2 is owned by glibc 2.16.0-1
> /lib/libnss_hesiod-2.16.so is owned by glibc 2.16.

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Wed, 18 Jul 2012 09:22:53 +0200
Tom Gundersen  wrote:

> On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC
>  wrote:
> > On Wed, 18 Jul 2012 00:46:49 +0200
> > Tom Gundersen  wrote:
> >
> >> On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC
> >>  wrote:
> >> > Right after much faffing about  i now have the box back to
> >>
> >> So if /lib is NOT a symlink, then all you should need is to delete
> >> all the files in /usr/lib that are not owned by any package. Then
> >> you should be able to upgrade.
> >
> > Hi .
> >
> > Right i have sort of put a list together but well  see below ..
> 
> You just have to delete the files that show up as being in conflict
> when you try to upgrade. Just make sure that 1) /lib is not a symlink
> and 2) those files are not owned by any other package.
> 
> -t

Hu  ..

No matter what it try  it still boils down to this list of errors 

error: failed to commit transaction (conflicting files)
glibc: /usr/lib/ld-2.16.so exists in filesystem
glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem
glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
glibc: /usr/lib/libSegFault.so exists in filesystem
glibc: /usr/lib/libanl-2.16.so exists in filesystem
glibc: /usr/lib/libanl.so.1 exists in filesystem
glibc: /usr/lib/libc-2.16.so exists in filesystem
glibc: /usr/lib/libc.so.6 exists in filesystem
glibc: /usr/lib/libcidn-2.16.so exists in filesystem
glibc: /usr/lib/libcidn.so.1 exists in filesystem
glibc: /usr/lib/libcrypt-2.16.so exists in filesystem
glibc: /usr/lib/libcrypt.so.1 exists in filesystem
glibc: /usr/lib/libdl-2.16.so exists in filesystem
glibc: /usr/lib/libdl.so.2 exists in filesystem
glibc: /usr/lib/libm-2.16.so exists in filesystem
glibc: /usr/lib/libm.so.6 exists in filesystem
glibc: /usr/lib/libmemusage.so exists in filesystem
glibc: /usr/lib/libnsl-2.16.so exists in filesystem
glibc: /usr/lib/libnsl.so.1 exists in filesystem
glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem
glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
glibc: /usr/lib/libnss_db-2.16.so exists in filesystem
glibc: /usr/lib/libnss_db.so.2 exists in filesystem
glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem
glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
glibc: /usr/lib/libnss_files-2.16.so exists in filesystem
glibc: /usr/lib/libnss_files.so.2 exists in filesystem
glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem
glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem
glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem
glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
glibc: /usr/lib/libpcprofile.so exists in filesystem
glibc: /usr/lib/libpthread-2.16.so exists in filesystem
glibc: /usr/lib/libpthread.so.0 exists in filesystem
glibc: /usr/lib/libresolv-2.16.so exists in filesystem
glibc: /usr/lib/libresolv.so.2 exists in filesystem
glibc: /usr/lib/librt-2.16.so exists in filesystem
glibc: /usr/lib/librt.so.1 exists in filesystem
glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
glibc: /usr/lib/libthread_db.so.1 exists in filesystem
glibc: /usr/lib/libutil-2.16.so exists in filesystem
glibc: /usr/lib/libutil.so.1 exists in filesystem
Errors occurred, no packages were upgraded.


lib is NOT a symlink  

 pacman -Qo /lib/*
/lib/ld-2.16.so is owned by glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
/lib/libanl-2.16.so is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/libm-2.16.so is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libnsl-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libnss_compat-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 is owned by glibc 2.16.0-1
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_files.so.2 is owned by glibc 2.16.0-1
/lib/libnss_hesiod-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nis-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is ow

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Wed, Jul 18, 2012 at 10:44 AM, Mauro Santos
 wrote:
> It's not in the wiki and I haven't seen it suggested but for really
> stubborn and possibly borked cases couldn't one boot from other media
> and tell pacman to update outside of the default path with --root,
> --cachedir, --config and --gpgdir? Or this a bad idea like using --force?

That should work (TM) :-)

-t

Re: [arch-general] Still Glibc problems

[Mauro Santos]

On 18-07-2012 08:09, Tom Gundersen wrote:
> On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills  wrote:
>> On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen  wrote:
>>> So if /lib is NOT a symlink, then all you should need is to delete all
>>> the files in /usr/lib that are not owned by any package. Then you
>>> should be able to upgrade.
>>
>> And if /lib IS a symbolic link, delete it and let the glibc sync create it.
> 
> No. Then you'll lose your loader and can't do anything...
> 

It's not in the wiki and I haven't seen it suggested but for really
stubborn and possibly borked cases couldn't one boot from other media
and tell pacman to update outside of the default path with --root,
--cachedir, --config and --gpgdir? Or this a bad idea like using --force?

-- 
Mauro Santos

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Wed, Jul 18, 2012 at 9:19 AM, P .NIKOLIC  wrote:
> On Wed, 18 Jul 2012 00:46:49 +0200
> Tom Gundersen  wrote:
>
>> On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC
>>  wrote:
>> > Right after much faffing about  i now have the box back to
>>
>> So if /lib is NOT a symlink, then all you should need is to delete all
>> the files in /usr/lib that are not owned by any package. Then you
>> should be able to upgrade.
>
> Hi .
>
> Right i have sort of put a list together but well  see below ..

You just have to delete the files that show up as being in conflict
when you try to upgrade. Just make sure that 1) /lib is not a symlink
and 2) those files are not owned by any other package.

-t

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Wed, 18 Jul 2012 09:09:18 +0200
Tom Gundersen  wrote:

> On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills 
> wrote:
> > On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen  wrote:
> >> So if /lib is NOT a symlink, then all you should need is to delete
> >> all the files in /usr/lib that are not owned by any package. Then
> >> you should be able to upgrade.
> >
> > And if /lib IS a symbolic link, delete it and let the glibc sync
> > create it.
> 
> No. Then you'll lose your loader and can't do anything...


Been there  not again thanks ..


Pete .

-- 
Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Wed, 18 Jul 2012 00:46:49 +0200
Tom Gundersen  wrote:

> On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC
>  wrote:
> > Right after much faffing about  i now have the box back to
> 
> So if /lib is NOT a symlink, then all you should need is to delete all
> the files in /usr/lib that are not owned by any package. Then you
> should be able to upgrade.

Hi .

Right i have sort of put a list together but well  see below ..

:error: No package owns /usr/lib/libanl-2.16.so
error: No package owns /usr/lib/libanl.so.1
error: No package owns /usr/lib/libBrokenLocale-2.16.so
error: No package owns /usr/lib/libBrokenLocale.so.1
error: No package owns /usr/lib/libc-2.16.so
error: cannot determine ownership of directory
'/usr/lib/libcanberra-0.28' error: No package
owns /usr/lib/libcidn-2.16.so error: No package
owns /usr/lib/libcidn.so.1 error: No package
owns /usr/lib/libcrypt-2.16.so error: No package
owns /usr/lib/libcrypt.so.1 error: No package owns /usr/lib/libc.so.6
error: No package owns /usr/lib/libdl-2.16.so
error: No package owns /usr/lib/libdl.so.2
error: cannot determine ownership of directory '/usr/lib/libfakeroot'
error: cannot determine ownership of directory '/usr/lib/libffi-3.0.11
error: cannot determine ownership of directory '/usr/lib/locale'
error: cannot determine ownership of directory '/usr/lib/man-db'
error: cannot determine ownership of directory '/usr/lib/mc'
error: cannot determine ownership of directory '/usr/lib/modprobe.d'
error: cannot determine ownership of directory '/usr/lib/modules'
error: cannot determine ownership of directory '/usr/lib/modules-load.d'
error: cannot determine ownership of directory '/usr/lib/mono'
error: cannot determine ownership of directory '/usr/lib/mozilla'
error: cannot determine ownership of directory '/usr/lib/mpg123'
1error: cannot determine ownership of directory '/usr/lib/mysql'
error: cannot determine ownership of directory '/usr/lib/networkmanager'
error: cannot determine ownership of directory '/usr/lib/ntrack'
error: cannot determine ownership of directory '/usr/lib/ocaml'

I have  a huge number of the directory complaints are they
ignoreable ..?

Pete .

-- 
Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Wed, Jul 18, 2012 at 3:11 AM, Andrew Hills  wrote:
> On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen  wrote:
>> So if /lib is NOT a symlink, then all you should need is to delete all
>> the files in /usr/lib that are not owned by any package. Then you
>> should be able to upgrade.
>
> And if /lib IS a symbolic link, delete it and let the glibc sync create it.

No. Then you'll lose your loader and can't do anything...

Re: [arch-general] Still Glibc problems

[Andrew Hills]

On Tue, Jul 17, 2012 at 6:46 PM, Tom Gundersen  wrote:
> So if /lib is NOT a symlink, then all you should need is to delete all
> the files in /usr/lib that are not owned by any package. Then you
> should be able to upgrade.

And if /lib IS a symbolic link, delete it and let the glibc sync create it.

--Andrew Hills

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Wed, Jul 18, 2012 at 12:19 AM, P .NIKOLIC  wrote:
> Right after much faffing about  i now have the box back to

So if /lib is NOT a symlink, then all you should need is to delete all
the files in /usr/lib that are not owned by any package. Then you
should be able to upgrade.

Re: [arch-general] Still Glibc problems

[Damjan]

grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc

returns nothing at all


Please try  that with

 grep -v "local/glibc-2.16.0"


grep -v glibc is too simple actually and will filter out lib32-glibc for 
example.


--
дамјан

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Tue, 17 Jul 2012 17:27:35 +0200
Tom Gundersen  wrote:



> 
> Hm how did /lib end up as a symlink to /usr/lib without those
> files being owned by glibc? Did you just copy it over manually and
> create the link yourself?
> 
> -t


Right after much faffing about  i now have the box back to 

 # pacman -Qo /lib/*
/lib/ld-2.16.so is owned by glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 is owned by glibc 2.16.0-1
/lib/libanl-2.16.so is owned by glibc 2.16.0-1
/lib/libanl.so.1 is owned by glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so is owned by glibc 2.16.0-1
/lib/libBrokenLocale.so.1 is owned by glibc 2.16.0-1
/lib/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn-2.16.so is owned by glibc 2.16.0-1
/lib/libcidn.so.1 is owned by glibc 2.16.0-1
/lib/libcrypt-2.16.so is owned by glibc 2.16.0-1
/lib/libcrypt.so.1 is owned by glibc 2.16.0-1
/lib/libc.so.6 is owned by glibc 2.16.0-1
/lib/libdl-2.16.so is owned by glibc 2.16.0-1
/lib/libdl.so.2 is owned by glibc 2.16.0-1
/lib/libm-2.16.so is owned by glibc 2.16.0-1
/lib/libmemusage.so is owned by glibc 2.16.0-1
/lib/libm.so.6 is owned by glibc 2.16.0-1
/lib/libnsl-2.16.so is owned by glibc 2.16.0-1
/lib/libnsl.so.1 is owned by glibc 2.16.0-1
/lib/libnss_compat-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_compat.so.2 is owned by glibc 2.16.0-1
/lib/libnss_db-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_db.so.2 is owned by glibc 2.16.0-1
/lib/libnss_dns-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_dns.so.2 is owned by glibc 2.16.0-1
/lib/libnss_files-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_files.so.2 is owned by glibc 2.16.0-1
/lib/libnss_hesiod-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_hesiod.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nis-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus-2.16.so is owned by glibc 2.16.0-1
/lib/libnss_nisplus.so.2 is owned by glibc 2.16.0-1
/lib/libnss_nis.so.2 is owned by glibc 2.16.0-1
/lib/libpcprofile.so is owned by glibc 2.16.0-1
/lib/libpthread-2.16.so is owned by glibc 2.16.0-1
/lib/libpthread.so.0 is owned by glibc 2.16.0-1
/lib/libresolv-2.16.so is owned by glibc 2.16.0-1
/lib/libresolv.so.2 is owned by glibc 2.16.0-1
/lib/librt-2.16.so is owned by glibc 2.16.0-1
/lib/librt.so.1 is owned by glibc 2.16.0-1
/lib/libSegFault.so is owned by glibc 2.16.0-1
/lib/libthread_db-1.0.so is owned by glibc 2.16.0-1
/lib/libthread_db.so.1 is owned by glibc 2.16.0-1
/lib/libutil-2.16.so is owned by glibc 2.16.0-1
/lib/libutil.so.1 is owned by glibc 2.16.0-1

and 

grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc

returns nothing at all 

so now how do i get to install the new glibc 

all i get right now is 

error: failed to commit transaction (conflicting files)
glibc: /usr/lib/ld-2.16.so exists in filesystem
glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem
glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
glibc: /usr/lib/libSegFault.so exists in filesystem
glibc: /usr/lib/libanl-2.16.so exists in filesystem
glibc: /usr/lib/libanl.so.1 exists in filesystem
glibc: /usr/lib/libc-2.16.so exists in filesystem
glibc: /usr/lib/libc.so.6 exists in filesystem
glibc: /usr/lib/libcidn-2.16.so exists in filesystem
glibc: /usr/lib/libcidn.so.1 exists in filesystem
glibc: /usr/lib/libcrypt-2.16.so exists in filesystem
glibc: /usr/lib/libcrypt.so.1 exists in filesystem
glibc: /usr/lib/libdl-2.16.so exists in filesystem
glibc: /usr/lib/libdl.so.2 exists in filesystem
glibc: /usr/lib/libm-2.16.so exists in filesystem
glibc: /usr/lib/libm.so.6 exists in filesystem
glibc: /usr/lib/libmemusage.so exists in filesystem
glibc: /usr/lib/libnsl-2.16.so exists in filesystem
glibc: /usr/lib/libnsl.so.1 exists in filesystem
glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem
glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
glibc: /usr/lib/libnss_db-2.16.so exists in filesystem
glibc: /usr/lib/libnss_db.so.2 exists in filesystem
glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem
glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
glibc: /usr/lib/libnss_files-2.16.so exists in filesystem
glibc: /usr/lib/libnss_files.so.2 exists in filesystem
glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem
glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem
glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem
glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
glibc: /usr/lib/libpcprofile.so exists in filesystem
glibc: /usr/lib/libpthread-2.16.so exists in filesystem
glibc: /usr/lib/libpthread.so.0 exists in filesystem
glibc: /usr/lib/libresolv-2.16.so exists in filesystem
glibc: /usr/lib/libresolv.so.2 exists in filesystem
glibc: /usr/lib/librt-2.16.so exists in filesystem
glibc: /usr/lib/librt.so.1 exists in filesystem
glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
glibc: /usr/lib/libthread_db.so.1 exists i

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Tue, 17 Jul 2012 18:27:24 +0200
Guus Snijders  wrote:

> Op 17 jul. 2012 18:01 schreef "P .NIKOLIC"
>  het volgende:
> >
> > On Tue, 17 Jul 2012 17:27:35 +0200
> > Tom Gundersen  wrote:
> >
> > Pruned
> > >
> > > Hm how did /lib end up as a symlink to /usr/lib without those
> > > files being owned by glibc? Did you just copy it over manually and
> > > create the link yourself?
> > >
> > > -t
> >
> > Quite easily
> >
> > I followed what was on the Arch web site and the links therein
> > nothing fancy
> 
> ;-)
> It might help to know which steps you took.
> 
> Afaik, the instructions were to check if any files were still in /lib
> -other then glibc's- and to rebuild those packages. But maybe you
> took some other steps?
> 
> Checking the ownership of files in the symlinked /lib has little
> purpose.
> 
> Just my two cents.
> 
> mvg, Guus

Hi ..


this is the link that got the box running again ..
https://bbs.archlinux.org/viewtopic.php?pid=1127251#p1127251



Pete ..



-- 
Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[Guus Snijders]

Op 17 jul. 2012 18:01 schreef "P .NIKOLIC"  het
volgende:
>
> On Tue, 17 Jul 2012 17:27:35 +0200
> Tom Gundersen  wrote:
>
> Pruned
> >
> > Hm how did /lib end up as a symlink to /usr/lib without those
> > files being owned by glibc? Did you just copy it over manually and
> > create the link yourself?
> >
> > -t
>
> Quite easily
>
> I followed what was on the Arch web site and the links therein
> nothing fancy

;-)
It might help to know which steps you took.

Afaik, the instructions were to check if any files were still in /lib
-other then glibc's- and to rebuild those packages. But maybe you took some
other steps?

Checking the ownership of files in the symlinked /lib has little purpose.

Just my two cents.

mvg, Guus

Re: [arch-general] Still Glibc problems

[P .NIKOLIC]

On Tue, 17 Jul 2012 17:27:35 +0200
Tom Gundersen  wrote:

Pruned
> 
> Hm how did /lib end up as a symlink to /usr/lib without those
> files being owned by glibc? Did you just copy it over manually and
> create the link yourself?
> 
> -t

Quite easily

I followed what was on the Arch web site and the links therein
nothing fancy 

Pete .


-- 
Linux 7-of-9 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012
x86_64 GNU/Linux

Re: [arch-general] Still Glibc problems

[Tom Gundersen]

On Tue, Jul 17, 2012 at 5:19 PM, P .NIKOLIC  wrote:
> I have followed all there is to follow tried all i can find to try yet
> i am still getting
>
> error: failed to commit transaction (conflicting files)
> glibc: /lib exists in filesystem
> glibc: /usr/lib/ld-2.16.so exists in filesystem
> glibc: /usr/lib/ld-linux-x86-64.so.2 exists in filesystem
> glibc: /usr/lib/libBrokenLocale-2.16.so exists in filesystem
> glibc: /usr/lib/libBrokenLocale.so.1 exists in filesystem
> glibc: /usr/lib/libSegFault.so exists in filesystem
> glibc: /usr/lib/libanl-2.16.so exists in filesystem
> glibc: /usr/lib/libanl.so.1 exists in filesystem
> glibc: /usr/lib/libc-2.16.so exists in filesystem
> glibc: /usr/lib/libc.so.6 exists in filesystem
> glibc: /usr/lib/libcidn-2.16.so exists in filesystem
> glibc: /usr/lib/libcidn.so.1 exists in filesystem
> glibc: /usr/lib/libcrypt-2.16.so exists in filesystem
> glibc: /usr/lib/libcrypt.so.1 exists in filesystem
> glibc: /usr/lib/libdl-2.16.so exists in filesystem
> glibc: /usr/lib/libdl.so.2 exists in filesystem
> glibc: /usr/lib/libm-2.16.so exists in filesystem
> glibc: /usr/lib/libm.so.6 exists in filesystem
> glibc: /usr/lib/libmemusage.so exists in filesystem
> glibc: /usr/lib/libnsl-2.16.so exists in filesystem
> glibc: /usr/lib/libnsl.so.1 exists in filesystem
> glibc: /usr/lib/libnss_compat-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_compat.so.2 exists in filesystem
> glibc: /usr/lib/libnss_db-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_db.so.2 exists in filesystem
> glibc: /usr/lib/libnss_dns-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_dns.so.2 exists in filesystem
> glibc: /usr/lib/libnss_files-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_files.so.2 exists in filesystem
> glibc: /usr/lib/libnss_hesiod-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_hesiod.so.2 exists in filesystem
> glibc: /usr/lib/libnss_nis-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_nis.so.2 exists in filesystem
> glibc: /usr/lib/libnss_nisplus-2.16.so exists in filesystem
> glibc: /usr/lib/libnss_nisplus.so.2 exists in filesystem
> glibc: /usr/lib/libpcprofile.so exists in filesystem
> glibc: /usr/lib/libpthread-2.16.so exists in filesystem
> glibc: /usr/lib/libpthread.so.0 exists in filesystem
> glibc: /usr/lib/libresolv-2.16.so exists in filesystem
> glibc: /usr/lib/libresolv.so.2 exists in filesystem
> glibc: /usr/lib/librt-2.16.so exists in filesystem
> glibc: /usr/lib/librt.so.1 exists in filesystem
> glibc: /usr/lib/libthread_db-1.0.so exists in filesystem
> glibc: /usr/lib/libthread_db.so.1 exists in filesystem
> glibc: /usr/lib/libutil-2.16.so exists in filesystem
> glibc: /usr/lib/libutil.so.1 exists in filesystem
> Errors occurred, no packages were upgraded.
>
> What has got to be done to solve this once and for all ..
> lib is a symlink to usr/lib..

Hm how did /lib end up as a symlink to /usr/lib without those
files being owned by glibc? Did you just copy it over manually and
create the link yourself?

-t