/lib Removal Heads Up

ArchVortex · 2012-07-07 11:45:50

EDIT please read post 10 for more information

From Dave Reisner:

Hey all,
Allan pushed glib 2.16-2 into [testing] which removes /lib as a
directory, replacing it with a symlink. A bit of advice...
- In the simplest case, the upgrade can be done as simply as:
pacman -Syu --ignore glibc && pacman -S glibc
- Since nothing is ever simple, if the above still fails on installation
of glibc (with a somewhat cryptic "/lib exists" error), you'll need to
figure out what's still in /lib that doesn't belong to glibc.
Generally this will end up being modules/. pacman -Qo /lib/* will
pinpoint what needs fixing/removing. Deal with anything that isn't
owned explicitly by glibc and complete the installation.
It shouldn't need to be said, but I'll mention it anyways:
Do. Not. Use. (the) --force. Obi-wan approves of this.

Edit by Pablokal: So DO NOT USE --force! This will seriously break your system.

Error message will something like: failed to commit transaction (conflicting files) glibc

Related threads:
http://bbs.archbang.org/viewtopic.php?pid=16500#p16500

http://bbs.archbang.org/viewtopic.php?pid=16511

ArchVortex · 2012-07-07 12:18:25

Just tried the instructions and it didn't upgrade. Played around removing all the stuff from /lib that was not connected to glibc and hosed my testing partition.

My advice is hold off upgrading til this /lib symlink crap is sorted out. This why I run a testing partition in case crap like this happens so I can warn ArchBangers. Never have this problem with Gentoo and Slackware Time to set up a new testing partition.

oliver · 2012-07-07 18:21:10

I wonder what possible benefit there is to changing this to a symlink

ArchVortex · 2012-07-10 18:50:40

Allan McRae allan@archlinux.org
5:26 AM (2 hours ago)

to Public
A patched version of pacman is now in [testing] that will detect all the
issues reported so far that resulted in failed updates. Users of the
[testing] repo who last updated in the three days between the kmod
update and the glibc update may still run into issues, but "pacman -Sy
pacman && pacman -Su" will prevent that.

Here is a (very draft) news item. I think it provides complete update
instructions for people using the "stable" repos.

Removal of /lib directory

All files in the /lib directory have been moved to /usr/lib and now /lib
is a symlink to usr/lib. During this update, pacman will identify a
conflict in the /lib directory. In the simplest case, this is worked
around by doing

pacman -Syu --ignore glibc
pacman -Su

When additional package depend on having a newer version of glibc than
is currently on your system and these also have files in /lib (e.g.
older versions of gcc), then and extra step will be necessary. For example:

pacman -Syu --ignore glibc gcc
pacman -Sd gcc
pacman -Su

Only do the -Sd step if really necessary. Pacman will warn you about a
conflict in /lib on the -Su step if it is.

If the "pacman -Su" step reports a conflict in /lib, you will need to
look at all the files in /lib and determine which ones are not owned by
glibc. This is achieved by "pacman -Qo /lib/*". You will need to move
any files not belong to glibc to /usr/lib (either through fixing their
package or manually moving unowned files). There should be no
subdirectories in /lib either.

Finally, NEVER use pacman --force (-f) for the glibc update. That will
result in a broken system.

ArchVortex · 2012-07-11 22:12:24

This post by felixonmars might help some who FUBAR their system https://bbs.archlinux.org/viewtopic.php … 7#p1126667

Mr Green · 2012-07-11 23:46:20

We may run into other package problems, after reading thread

find /var/lib/pacman/local -name files | xargs grep "^lib/$"
/var/lib/pacman/local/glibc-2.16.0-1/files:lib/
/var/lib/pacman/local/linux-headers-3.4.4-2/files:lib/
/var/lib/pacman/local/nvidia-302.17-1/files:lib/
/var/lib/pacman/local/virtualbox-modules-4.1.18-1/files:lib/
/var/lib/pacman/local/linux-3.4.4-2/files:lib/
/var/lib/pacman/local/lib32-glibc-2.15-6/files:lib/
/var/lib/pacman/local/broadcom-wl-5.100.82.112-4/files:lib/

Most will get upgraded, broadcom-wl from AUR may not

ArchVortex · 2012-07-12 00:31:55

Follow Allan's instructions for Issue #1 at

https://wiki.archlinux.org/index.php/De … iki:usrlib

Then you'll find that Broadcom causes an upgrade problem for ArchBang. By running

# find /lib -exec pacman -Qo -- '{}' \+

you will see in your output that

/lib/modules/extramodules-3.4-ARCH/wl.ko.gz is owned by broadcom-wl 5.100.82.112-4

is messing up the upgrade. Remove broadcom-wl

# pacman -R broadcom-wl

and then re-execute

# pacman -Su

and glibc should install and the symlink from /lib to /usr/lib should be in place.

Mr Green · 2012-07-12 01:55:56

So guess I will hold off any further iso builds until /lib issue is sorted [main repos]

Have a feeling that build scripts and abinstall will need more work

Not to mention grub2.....

pablokal · 2012-07-13 13:58:48

Well uninstalling to be needed to update is not so unusual in Arch/pacman; normally they cover this for you with update suggestions or warnings..

Mr Green · 2012-07-14 11:47:07

http://www.archlinux.org/news/the-lib-d … a-symlink/

All users should be aware of possible upgrade issues

Handy page for those having problems

https://wiki.archlinux.org/index.php/De … iki:usrlib

For ArchBang users broadcom-wl will need either to be rebuilt/updated or removed

http://aur.archlinux.org/packages.php?ID=19514

pablokal · 2012-07-17 06:41:53

This didn't go automatically well when I updated.
Although a new version of pacman was installed that put glibc in the not to update section.
The reason is that archiso-git was installed and had left some folders in /lib.
I first had to uninstall this.
But at first I got the impression everything was OK, I didn't get a notification that there where problems.
That is the reason of this post.
I just noticed some programs weren't working as they should.
I couldn't rebuild mplayer-vdpau-svn which really annoyed me as the quality of the ordinary mplayer is really a step back.
Also wine wouldn't start up.
The best way to check if you have problems or not is to do this:

Success
You can confirm the update is complete by looking in your root directory to see that lib is a symlink to usr/lib.
$ ls -ld /lib
lrwxrwxrwx 1 root root 7 Jul 11 21:10 lib -> usr/lib

What showed me that what was wrong:

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

and

and any directories within /lib need deleted (after they are empty...).

So I had to uninstall archiso-git and to delete the folders.
Then I still had to do

#pacman -Su

and glibc could be updated.
And then finally

 ls -ld /lib

gave the desired output.

mike4ca · 2012-07-19 20:57:46

For me, I had an install that has only the lts kernel. It had stuff in the /lib folder and would not let the upgrade proceed. So I had to install the normal kernel, add a grub item for that kernel, reboot into the normal kernel, then remove the lts kernel. I could proceed with the glibc install and upgrade from there. When done, I installed the lts kernel back.

pablokal · 2012-07-20 03:53:31

Gee, what a hassle!! I have both installed and could leave the lts kernel at its place.

Arch Linux

Announcement

#1 2012-07-07 11:45:50

/lib Removal Heads Up

EDIT please read post 10 for more information

#2 2012-07-07 12:18:25

Re: /lib Removal Heads Up

#3 2012-07-07 18:21:10

Re: /lib Removal Heads Up

#4 2012-07-10 18:50:40

Re: /lib Removal Heads Up

#5 2012-07-11 22:12:24

Re: /lib Removal Heads Up

#6 2012-07-11 23:46:20

Re: /lib Removal Heads Up

#7 2012-07-12 00:31:55

Re: /lib Removal Heads Up

#8 2012-07-12 01:55:56

Re: /lib Removal Heads Up

#9 2012-07-13 13:58:48

Re: /lib Removal Heads Up

#10 2012-07-14 11:47:07

Re: /lib Removal Heads Up

#11 2012-07-17 06:41:53

Re: /lib Removal Heads Up

#12 2012-07-19 20:57:46

Re: /lib Removal Heads Up

#13 2012-07-20 03:53:31

Re: /lib Removal Heads Up

Board footer