[arch-general] Still Glibc problems

Tom Gundersen teg at jklm.no
Fri Jul 20 10:41:39 EDT 2012


On Fri, Jul 20, 2012 at 12:13 PM, Guus Snijders <gsnijders at gmail.com> 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


More information about the arch-general mailing list