that's a completely different issue and has nothing to do with this thead, it should be in it's own thread.
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.
]]>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.
]]>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!
]]>Thank`s a lot it is great news.
]]>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
]]>And I do hope that there are some people who solved similar problem.
Once again, thank you.
]]>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.
]]>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 ...
]]>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.
BUT, instead of creating a thread, a quick search of the Wiki should tell you what to do.
]]>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 ?
]]>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/