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, 01:42 PM
fredbezies
 
Default Glibc 2.16.0-2 in testing killed my system.

Hello.

I upgraded a few minutes ago my archlinux + testing installation. As I
cannot install glibc (because of some AUR software which had links or
binary in /lib), I made the mistake of forcing installation. My system
is dead. I will try repairing using archboot on an USB key.

Maybe this version needs to be retired. Well I'm kinda annoyed by this bug

--
Frederic Bezies
fredbezies@gmail.com
 
Old 07-07-2012, 01:54 PM
Tom Gundersen
 
Default Glibc 2.16.0-2 in testing killed my system.

On Sat, Jul 7, 2012 at 3:42 PM, fredbezies <fredbezies@gmail.com> wrote:
> I upgraded a few minutes ago my archlinux + testing installation. As I
> cannot install glibc (because of some AUR software which had links or
> binary in /lib), I made the mistake of forcing installation. My system
> is dead. I will try repairing using archboot on an USB key.

This is expected behavior. It is good you mention this on the list, to
remind everyone that you should never use --force unless you really,
really know exactly what is going to happen.

In this case glibc moved from /lib to /usr/lib. The upgrade should
have replaced /lib by a symlink to /usr/lib. This is necessary to make
the linker keep working. However, since you had some stuff from AUR
still in /lib this did not work. The correct solution would have been
to move that stuff out of the way, so that the upgrade could continue
normally.

Since you used --force, however, pacman ignored the fact that the
symlink could not be created and basically hosed your system.

It should be simple enough to fix though: mount your root from a
rescue system, empty /lib manually and replace it with a symlink to
/usr/lib. Assuming I guessed correctly at what exactly happened that
is.

Cheers,

Tom
 
Old 07-07-2012, 02:57 PM
Uli Armbruster
 
Default Glibc 2.16.0-2 in testing killed my system.

* Tom Gundersen <teg@jklm.no> [07.07.2012 15:55]:
> On Sat, Jul 7, 2012 at 3:42 PM, fredbezies <fredbezies@gmail.com> wrote:
> > I upgraded a few minutes ago my archlinux + testing installation. As I
> > cannot install glibc (because of some AUR software which had links or
> > binary in /lib), I made the mistake of forcing installation. My system
> > is dead. I will try repairing using archboot on an USB key.
>
> This is expected behavior. It is good you mention this on the list, to
> remind everyone that you should never use --force unless you really,
> really know exactly what is going to happen.
>
> In this case glibc moved from /lib to /usr/lib. The upgrade should
> have replaced /lib by a symlink to /usr/lib. This is necessary to make
> the linker keep working. However, since you had some stuff from AUR
> still in /lib this did not work. The correct solution would have been
> to move that stuff out of the way, so that the upgrade could continue
> normally.
>
> Since you used --force, however, pacman ignored the fact that the
> symlink could not be created and basically hosed your system.
>
> It should be simple enough to fix though: mount your root from a
> rescue system, empty /lib manually and replace it with a symlink to
> /usr/lib. Assuming I guessed correctly at what exactly happened that
> is.
>
> Cheers,
>
> Tom

I have the same problem, but I didn't force the update

Here's what pacman spits out

:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (2):

Name Old Version New Version Net Change Download Size

glibc 2.16.0-1 2.16.0-2 0.00 MiB
lib32-glibc 2.16.0-1 2.16.0-2 -0.18 MiB

Total Installed Size: 51.95 MiB
Net Upgrade Size: -0.19 MiB

Proceed with installation? [Y/n]
(2/2) checking package integrity [-------------------------------------] 100%
(2/2) loading package files [-------------------------------------] 100%
(2/2) checking for file conflicts [-------------------------------------] 100%
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
Errors occurred, no packages were upgraded.


So, looks like there's AUR-stuff in /lib, but I also get the following

# for i in /lib/*;do pacman -Qo $i;done
/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/ld-linux.so.2 is owned by lib32-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/libSegFault.so 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/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libc.so.6 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/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/libm.so.6 is owned by glibc 2.16.0-1
/lib/libmemusage.so 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_nis.so.2 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/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/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

Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?

I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.

Best
Army
 
Old 07-07-2012, 03:27 PM
Mantas Mikulėnas
 
Default Glibc 2.16.0-2 in testing killed my system.

On Sat, Jul 7, 2012 at 5:57 PM, Uli Armbruster
<uli.armbruster@googlemail.com> wrote:
> Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?
>
> I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.

I hit the same problem myself, and used `pacman -Rdd` to temporarily
remove lib32-glibc bypassing the dependency checks. After upgrade,
`pacman -S --asdeps lib32-glibc` to reinstall.


--
Mantas Mikulėnas
 
Old 07-07-2012, 03:34 PM
Ionut Biru
 
Default Glibc 2.16.0-2 in testing killed my system.

On 07/07/2012 06:27 PM, Mantas Mikulėnas wrote:
> On Sat, Jul 7, 2012 at 5:57 PM, Uli Armbruster
> <uli.armbruster@googlemail.com> wrote:
>> Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?
>>
>> I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.
>
> I hit the same problem myself, and used `pacman -Rdd` to temporarily
> remove lib32-glibc bypassing the dependency checks. After upgrade,
> `pacman -S --asdeps lib32-glibc` to reinstall.
>
>

a new update for lib32-glibc exists in multilib-testing. You don't have
that repo enabled?

--
Ionuț
 
Old 07-07-2012, 03:47 PM
Jan Steffens
 
Default Glibc 2.16.0-2 in testing killed my system.

On Sat, Jul 7, 2012 at 4:57 PM, Uli Armbruster
<uli.armbruster@googlemail.com> wrote:
> * Tom Gundersen <teg@jklm.no> [07.07.2012 15:55]:
>> On Sat, Jul 7, 2012 at 3:42 PM, fredbezies <fredbezies@gmail.com> wrote:
>> > I upgraded a few minutes ago my archlinux + testing installation. As I
>> > cannot install glibc (because of some AUR software which had links or
>> > binary in /lib), I made the mistake of forcing installation. My system
>> > is dead. I will try repairing using archboot on an USB key.
>>
>> This is expected behavior. It is good you mention this on the list, to
>> remind everyone that you should never use --force unless you really,
>> really know exactly what is going to happen.
>>
>> In this case glibc moved from /lib to /usr/lib. The upgrade should
>> have replaced /lib by a symlink to /usr/lib. This is necessary to make
>> the linker keep working. However, since you had some stuff from AUR
>> still in /lib this did not work. The correct solution would have been
>> to move that stuff out of the way, so that the upgrade could continue
>> normally.
>>
>> Since you used --force, however, pacman ignored the fact that the
>> symlink could not be created and basically hosed your system.
>>
>> It should be simple enough to fix though: mount your root from a
>> rescue system, empty /lib manually and replace it with a symlink to
>> /usr/lib. Assuming I guessed correctly at what exactly happened that
>> is.
>>
>> Cheers,
>>
>> Tom
>
> I have the same problem, but I didn't force the update
>
> Here's what pacman spits out
>
> :: Starting full system upgrade...
> resolving dependencies...
> looking for inter-conflicts...
>
> Targets (2):
>
> Name Old Version New Version Net Change Download Size
>
> glibc 2.16.0-1 2.16.0-2 0.00 MiB
> lib32-glibc 2.16.0-1 2.16.0-2 -0.18 MiB
>
> Total Installed Size: 51.95 MiB
> Net Upgrade Size: -0.19 MiB
>
> Proceed with installation? [Y/n]
> (2/2) checking package integrity [-------------------------------------] 100%
> (2/2) loading package files [-------------------------------------] 100%
> (2/2) checking for file conflicts [-------------------------------------] 100%
> error: failed to commit transaction (conflicting files)
> glibc: /lib exists in filesystem
> Errors occurred, no packages were upgraded.
>
>
> So, looks like there's AUR-stuff in /lib, but I also get the following
>
> # for i in /lib/*;do pacman -Qo $i;done
> /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/ld-linux.so.2 is owned by lib32-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/libSegFault.so 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/libc-2.16.so is owned by glibc 2.16.0-1
> /lib/libc.so.6 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/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/libm.so.6 is owned by glibc 2.16.0-1
> /lib/libmemusage.so 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_nis.so.2 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/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/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
>
> Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?
>
> I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.
>
> Best
> Army

Updated lib32-glibc in [multilib-testing]. Just install glibc last.
$ pacman -Syu --ignore glibc
$ pacman -S glibc
 
Old 07-07-2012, 03:53 PM
Arno Gaboury
 
Default Glibc 2.16.0-2 in testing killed my system.

On 07/07/2012 05:47 PM, Jan Steffens wrote:

On Sat, Jul 7, 2012 at 4:57 PM, Uli Armbruster
<uli.armbruster@googlemail.com> wrote:

* Tom Gundersen <teg@jklm.no> [07.07.2012 15:55]:

On Sat, Jul 7, 2012 at 3:42 PM, fredbezies <fredbezies@gmail.com> wrote:

I upgraded a few minutes ago my archlinux + testing installation. As I
cannot install glibc (because of some AUR software which had links or
binary in /lib), I made the mistake of forcing installation. My system
is dead. I will try repairing using archboot on an USB key.

This is expected behavior. It is good you mention this on the list, to
remind everyone that you should never use --force unless you really,
really know exactly what is going to happen.

In this case glibc moved from /lib to /usr/lib. The upgrade should
have replaced /lib by a symlink to /usr/lib. This is necessary to make
the linker keep working. However, since you had some stuff from AUR
still in /lib this did not work. The correct solution would have been
to move that stuff out of the way, so that the upgrade could continue
normally.

Since you used --force, however, pacman ignored the fact that the
symlink could not be created and basically hosed your system.

It should be simple enough to fix though: mount your root from a
rescue system, empty /lib manually and replace it with a symlink to
/usr/lib. Assuming I guessed correctly at what exactly happened that
is.

Cheers,

Tom

I have the same problem, but I didn't force the update

Here's what pacman spits out

:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (2):

Name Old Version New Version Net Change Download Size

glibc 2.16.0-1 2.16.0-2 0.00 MiB
lib32-glibc 2.16.0-1 2.16.0-2 -0.18 MiB

Total Installed Size: 51.95 MiB
Net Upgrade Size: -0.19 MiB

Proceed with installation? [Y/n]
(2/2) checking package integrity [-------------------------------------] 100%
(2/2) loading package files [-------------------------------------] 100%
(2/2) checking for file conflicts [-------------------------------------] 100%
error: failed to commit transaction (conflicting files)
glibc: /lib exists in filesystem
Errors occurred, no packages were upgraded.


So, looks like there's AUR-stuff in /lib, but I also get the following

# for i in /lib/*;do pacman -Qo $i;done
/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/ld-linux.so.2 is owned by lib32-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/libSegFault.so 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/libc-2.16.so is owned by glibc 2.16.0-1
/lib/libc.so.6 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/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/libm.so.6 is owned by glibc 2.16.0-1
/lib/libmemusage.so 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_nis.so.2 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/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/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

Is this caused by the fact that there are two packages with files in /lib ? How can I solve this problem? Is it ok this time to force the update?

I _could_ remove lib32-glibc first, run the update and then reinstall my lib32 stuff, since I don't have much lib32 stuff installed. But I think for many people this isn't an option! That's why I'm asking here.

Best
Army

*
Updated lib32-glibc in [multilib-testing]. Just install glibc last.
$ pacman -Syu --ignore glibc
$ pacman -S glibc
*
Is this the correct way to upgrade without breaking a system? Shall I
use with confidence this method?


TY for any hints.
 
Old 07-07-2012, 04:08 PM
Alexandre Ferrando
 
Default Glibc 2.16.0-2 in testing killed my system.

On 7 July 2012 17:53, Arno Gaboury <arnaud.gaboury@gmail.com> wrote:
> On 07/07/2012 05:47 PM, Jan Steffens wrote:
>> Updated lib32-glibc in [multilib-testing]. Just install glibc last.
>> $ pacman -Syu --ignore glibc
>> $ pacman -S glibc
>> *
>
> Is this the correct way to upgrade without breaking a system? Shall I use
> with confidence this method?
>
> TY for any hints.

Do as Jan said just before you asked.

Also, Check that /lib does not contain any directories not owned by
any package. I had a modules directory not owned by any package.
 
Old 07-08-2012, 07:53 AM
Uli Armbruster
 
Default Glibc 2.16.0-2 in testing killed my system.

* Jan Steffens <jan.steffens@gmail.com> [07.07.2012 17:48]:
> Updated lib32-glibc in [multilib-testing]. Just install glibc last.
> $ pacman -Syu --ignore glibc
> $ pacman -S glibc

Thanks, that did the trick
 
Old 07-08-2012, 02:33 PM
Myra Nelson
 
Default Glibc 2.16.0-2 in testing killed my system.

On Sun, Jul 8, 2012 at 2:53 AM, Uli Armbruster <
uli.armbruster@googlemail.com> wrote:
> * Jan Steffens <jan.steffens@gmail.com> [07.07.2012 17:48]:
>> Updated lib32-glibc in [multilib-testing]. Just install glibc last.
>> $ pacman -Syu --ignore glibc
>> $ pacman -S glibc
>
> Thanks, that did the trick

To all:

Check out these from dev-public. They help.

https://mailman.archlinux.org/pipermail/arch-dev-public/2012-July/023201.html
https://mailman.archlinux.org/pipermail/arch-dev-public/2012-July/023204.html

Myra
--
Life's fun when your sick and psychotic!
 

Thread Tools




All times are GMT. The time now is 03:02 PM.

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