You are not logged in.
I'm not sure what to do in order to avoid problems with this update..
The news says: "A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib."
So.. Should I first update every package except filesystem and glibc, then glibc, then filesystem?
EDIT: or rather ... Then glibc *and* filesystem as the news says
Last edited by simendsjo (2013-01-28 12:18:31)
Offline
Just do what it says. The easiest way is:
This will happen automatically when you run "pacman -Syu".
After taking care of any files in /usr/lib64 if they exist.
Last edited by loafer (2013-01-28 12:25:55)
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline
Is this solved?
I laugh, yet the joke is on me
Offline
Just do what it says. The easiest way is:
This will happen automatically when you run "pacman -Syu".
After taking care of any files in /usr/lib64 if they exist.
It's the "After taking care of" that baffles me. What am I supposed to do?
Offline
Just do pacman -Syu and see if pacman finds any conflicts. If there are conflicts pacman will notify you and not update. If so, first update everything apart from filesystem and glibc:
# pacman -Syu --ignore filesystem,glibc
Then try pacman -Syu again. There might be still conflicts because of some pacages from the AUR.
Offline
Just do pacman -Syu and see if pacman finds any conflicts. If there are conflicts pacman will notify you and not update.
So I should first try upgrading as normal?
If so, first update everything apart from filesystem and glibc:
# pacman -Syu --ignore filesystem,glibc
Then try pacman -Syu again. There might be still conflicts because of some pacages from the AUR.
.. And only run with --ignore if pacman warns about conflicts?
Offline
A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64.
$ sudo pacman -Syu
something about conflicting with /usr/lib64/foo
something about conflicting with /usr/lib64/bar
something about conflicting with /usr/lib64/aur
All Arch Linux packages that had files in this directory have been updated, so update these individually first.
$ pacman -Qo /usr/lib64/{foo,bar}
/usr/lib64/foo is owned by foopkg
/usr/lib64/bar is owned by barpkg
$ sudo pacman -S foopkg barpkg
Any AUR packages with files in this directory should be updated to install them in /usr/lib.
$ pacman -Qo /usr/lib64/aur
/usr/lib64/aur is owned by aurpkg
$ <update aurpkg from the AUR with the appropriate /usr/lib changes>
Done....
$ sudo pacman -Syu
Last edited by tdy (2013-01-28 17:00:28)
Offline
Thanks nuc and tdy.
pacman -Syu didn't give any errors, so everything went flawless.
Offline
Just to add some more info on this topic: on my system, /usr/lib64 was a symlink to /usr/lib before this upgrade. pacman -Syu complained about filesystem conflict. I did not see any mention of such symlinking anywhere in the news or forum posts, and I think it may be like this because I installed Arch as 32bit (stupidly) and then changed it to 64bit. In this case, removing /usr/lib64 and then upgrading worked fine.
I do wonder, however: after the upgrade, /usr/lib64 is symlinked to /lib, which is again symlinked to /usr/lib. Would it not be "nicer" to just symlink /usr/lib64 to /usr/lib?
Offline
Just to add some more info on this topic: on my system, /usr/lib64 was a symlink to /usr/lib before this upgrade. pacman -Syu complained about filesystem conflict. I did not see any mention of such symlinking anywhere in the news or forum posts, and I think it may be like this because I installed Arch as 32bit (stupidly) and then changed it to 64bit. In this case, removing /usr/lib64 and then upgrading worked fine.
I do wonder, however: after the upgrade, /usr/lib64 is symlinked to /lib, which is again symlinked to /usr/lib. Would it not be "nicer" to just symlink /usr/lib64 to /usr/lib?
It's already symlink to /usr/lib:
$ ls -l /usr/lib64
lrwxrwxrwx 1 root root 3 Jan 27 02:29 /usr/lib64 -> lib/
Offline
I just ran into this issue with existing printer support files in /usr/lib64. The way I resolved it was to rename /usr/lib64, then run "# pacman -Syu". After the system update, I compared files in /usr/lib with files in my renamed /usr/lib64, copied some regular files over and created some simlinks in /usr/lib where needed. I did all of this in /usr/lib, as /usr/lib64 is just a simlink now to /usr/lib.
Offline
HI all,
I am just trying to upgrade my system using "pacman -Suy". Here is an error :
error: failed to commit transaction (conflicting files)
filesystem: /lib exists in filesystem
fontconfig: /etc/fonts/conf.d/20-unhint-small-vera.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/29-replace-bitmap-fonts.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/30-metric-aliases.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/30-urw-aliases.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/40-nonlatin.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/45-latin.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/49-sansserif.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/50-user.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/51-local.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/60-latin.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/65-fonts-persian.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/65-nonlatin.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/69-unifont.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/80-delicious.conf exists in filesystem
fontconfig: /etc/fonts/conf.d/90-synthetic.conf exists in filesystem
Errors occurred, no packages were upgraded.
Oh, i have noticed that version of glibc and filesystem pacman wants to install doesn`t match:
filesystem-2013.01-3
glibc-2.17-3
Can anyone provide me any information how to fix this problem ?
Offline
iohanes, that's a completely different issue and has nothing to do with this thead, it should be in it's own thread.
BUT, instead of creating a thread, a quick search of the Wiki should tell you what to do.
Offline
Thank you for a quick reply!
I just wrote here because i think that it`s similar to my problem (i actually want to update filesystem-2013.01-1 and glibc-2.17-2 together ).
iohanes, that's a completely different issue and has nothing to do with this thead, it should be in it's own thread.
BUT, instead of creating a thread, a quick search of the Wiki should tell you what to do.
I red that wiki page for a few times. So main problem is that line is present in output error message :
filesystem: /lib exists in filesystem
...
I cannot solve this issue using your advice!
So, if you know how to do that, please tell me. I am badly stuck.
Offline
How long is it since you last updated?
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline
How long is it since you last updated?
I have not updated my system since July 2012 . So now i have such versions of libs:
glibc 2.16.0-1
filesystem 2012.7-1
I have searched a lot about but still nothing ...
Offline
Allan McRae pointed out in an email to arch-dev-public that users who have not updated in 6 months may have additional problems. However, if you don't use [testing] you probably don't subscribe.
I am sorry but I do not know an easy fix. Perhaps you could go through all the news items since July 2012 and try to tackle each major change in turn.
I'm surprised there aren't any other threads about this.
Hopefully someone else will have a better idea than me.
All men have stood for freedom...
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.
Offline
Thanks a lot, loafer. I have a some time to find solution (till Saturday) . So, I`ll write here about my success.
And I do hope that there are some people who solved similar problem.
Once again, thank you.
Offline
Thanks a lot, loafer. I have a some time to find solution (till Saturday) . So, I`ll write here about my success.
And I do hope that there are some people who solved similar problem.
Once again, thank you.
I've got exactly the same problem today (some rarely maintained machine). Of course that's not the only solution, but it worked for me. Key part was getting a little bit older packages from Arch Rollback Machine, namely filesystem-2012.12-1-any.pkg.tar.xz and glibc-2.17-1-x86_64.pkg.tar.xz along with their signatures if required. My choice of packages from the 31st of the last december was, frankly speaking, random. But I'm getting ahead of myself .
First I, more or less, followed DeveloperWiki:usrlib in regard of doing
pacman -Syu --ignore glibc
but instead of ignoring just glibc I ignored filesystem too
pacman -Syu --ignore glibc,filesystem
Then I think I upgraded gcc-libs and binuntils with
pacman -Sd binutils gcc-libs
This brought me to the point where my sole problem was /lib existsing in the filesystem. Then I used previously downloaded packages from ARM:
pacman -U <path-to-file>/filesystem-2012.12-1-any.pkg.tar.xz <path-to-file>/glibc-2.17-1-x86_64.pkg.tar.xz
This was enough to transform /lib and /lib64 to symlinks and provide glibc-2.17 to previously upgraded packages. One thing remained:
pacman -Su
which went smoothly and that was it.
Of course my system was x86_64 here so i686 people have to take note of that.
I hope this will be of any help and that I didn't miss or messed up any steps :}.
[Edit] Some minor grammar and punctuation changes
Last edited by TheBodziO (2013-02-06 14:17:41)
It's not the best thing when they call you a "member" you know…
Offline
Thank you very much !
I`ll try your solution in the evening (now I am not at home). I had a similar idea but I wasn`t sure.
Thank`s a lot it is great news.
Offline
I`ll try your solution in the evening (now I am not at home). I had a similar idea but I wasn`t sure.
Good luck with your update! I'm looking forward to hear of the results!
It's not the best thing when they call you a "member" you know…
Offline
Thank you all and especially to TheBodzio!
I should say that that solution provided by TheBodzio is great (main problem seems like solved). But I`ve got a kernel panic (it is only my false, I was very sleepy yesterday, so i crashed my system and it`s very hard to recall what caused that).
Nevertheless it was a very useful experience for me. Now I am writing from my new reinstalled Arch and I am glad(as i placed my /home directory to separate partition). Everything works fine.
Thank you ,guys.
Offline
Thank you all and especially to TheBodzio!
I should say that that solution provided by TheBodzio is great (main problem seems like solved).
Don't mention it
But I`ve got a kernel panic (it is only my false, I was very sleepy yesterday, so i crashed my system and it`s very hard to recall what caused that).
Sorry to hear that. Maybe it was initrd? I can't really remember if I regenerated it with mkinitcpio or not.
Nevertheless it was a very useful experience for me.
Each breakage brings you closer to the enlightenment
Now I am writing from my new reinstalled Arch and I am glad(as i placed my /home directory to separate partition). Everything works fine.
I'm glad everything's back and running at your side
As for rescuing damaged Arch installation (well… not only Arch but that's a different story ) I recommend you to take a look at https://wiki.archlinux.org/index.php/Change_Root. Among other things it's very useful “CPR technique”. You can boot from other media (like Arch install USB drive; architecture—i686 or x86_64—ought to be the same on both target and booted system) mount your system's partitions and chroot to them to perform the magic like running mkinitcpio to recreate missing or faulty initrd images. Using running kernel as a scaffold, you are able to rebuild damaged things that prevented your system from booting. Arch and quite a few distros use chroot in their installation process.
It's not the best thing when they call you a "member" you know…
Offline
This still applies.. the issues are getting more and more off-topic....
that's a completely different issue and has nothing to do with this thead, it should be in it's own thread.
Last edited by tdy (2013-02-08 21:57:37)
Offline