On 08/07/12 03:25, Dave Reisner wrote:

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.

So... this upgrade has been more fun than expected. At the moment there appears to a "limitation" in pacman so I would recommend updating like: Step 0) open a root shell - this can be used to recover if anything goes wrong Step 1) run: pacman -Qo /lib/* Deal with (either via updating from the repo or rebuilding) anything not owned by glibc Step 2) run: find /var/lib/pacman/local -name files | xargs grep "^lib/$" This should only return glibc. If not, rebuild those packages not to own the /lib directory Step 3) pacman -Syu If something goes wrong (you will see a message like "call to execv failed"), use your root shell to do: /usr/lib/ld-2.16.so /bin/rm -r /lib /usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib Note that all this should have been unnecessary and the instructions given by falconindy should have been enough. But there appears to be a genuine pacman bug in conflict checking where it ignores other packages owning a directory when it checks if it can be removed. Hopefully this can be fixed soon... There may be something else going on with here too, but we are unsure as of yet. Note that pacman will detect when there are files in /lib that do not belong to glibc before upgrade, just not if some other package owns /lib only (with no files). So all the cases I tested (folder and files in /lib, both owned and unowned by packages) do not result in the error. Allan

On 08/07/12 23:36, Jan de Groot wrote:

On za, 2012-07-07 at 13:25 -0400, Dave Reisner wrote:

...

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.

I didn't need --force to fuck up my system. When I upgraded like above, I got file conflicts because of some depmod files in /lib/modules, combined with an old ancient udev-compat package. I removed udev-compat and the files, but there were still some empty directories in /lib. When running pacman -S glibc, pacman didn't detect any file conflicts, installed the new glibc, told me that it could not extract /lib and then left my system in a state that couldn't execute a single command anymore.

Thanks, that was a case I had missed in patching pacman to detect these conflicts early. These two patches should catch all issues noted so far during the conflict checking stage and prevent these rouge extractions: http://mailman.archlinux.org/pipermail/pacman-dev/2012-July/015678.html http://mailman.archlinux.org/pipermail/pacman-dev/2012-July/015679.html Allan

On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae wrote:

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

find /lib -print0 | xargs -o pacman -Qo is much more effective at helping track down pesky files in subdirectories (ala catalyst-hook).

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.

This package tripped me up for a while; what's the expected easy update path for those of us with it installed? Adding another three steps like `pacman -Rdd lib32-glibc`, then above commands, then reinstall seems very crazy to me, but that was the only way I found. lib32-glibc /lib/ lib32-glibc /lib/ld-linux.so.2

On 11/07/12 12:25, Allan McRae wrote:

On 11/07/12 11:32, Dan McGee wrote:

...

On Tue, Jul 10, 2012 at 5:26 PM, Allan McRae wrote:

...

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

find /lib -print0 | xargs -o pacman -Qo is much more effective at helping track down pesky files in subdirectories (ala catalyst-hook).

I figure that: error: cannot determine ownership of directory '/lib/foo' is a good hint, because these directories need removed too.

We probably need to add a note about looking for packages that own /lib but seem to have no actual files in there (probably because the files were manually moved to /usr/lib...). This will give a conflict on /lib. So some sort of: grep -R --include files "^lib" /var/lib/pacman/local/ I think the news announcement is probably getting a bit long given all the esge cases that should be covered. I will just include instructions for the ideal (usual?) case of "pacman -Syu --ignore glibc && pacman -Su" and provide a link to a (as yet uncreated...) wiki page with instructions on how to deal with conflicts. Allan

News draft --- 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 If either of this steps gives issues (e.g. dependency version issues, file conflicts in /lib), refer to this [guide](https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib) for more detailed instructions on performing this upgrade. --- I will post this soon and move the packages about a day later. Allan

On Sat, Jul 14, 2012 at 11:10:57AM +1000, Allan McRae wrote:

On 14/07/12 10:42, Allan McRae wrote:

...

News draft

---

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

If either of this steps gives issues (e.g. dependency version issues, file conflicts in /lib), refer to this [guide](https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib) for more detailed instructions on performing this upgrade.

---

I will post this soon and move the packages about a day later.

Packages to be moved:

[core/extra] bash-completion binutils bitlbee fcpci fcpcmcia glibc kmod linux linux-lts lirc nvidia nvidia-lts syslog-ng systemd

Also: kdebase-workspace xorg-xdm both needed changes to their services for systemd-186.

[community] cdfs dkms libflashsupport-oss ndiswrapper open-vm-tools-modules oss r8168 r8168-lts rsyslog rt3562sta systemd-arch-units vhba-module virtualbox virtualbox-modules virtualbox-modules-lts

[multilib] lib32-glibc