X problems on FC8 x86_64

[nicolang]

This is a bit embarrassing I have an FC8 x86_64 box and I was in the process of updating/installing various programs and libraries for a project that I am starting up (was looking for easy-to-use ray tracing suites etc。 I came across blender (since this seemed to be the answer to what I was looking for .. a program which can import/export povray data) and tried to install it, but there were some dependencies which it wanted to install, leading to error messages during the attempted install. Somehow, this stuffed up my system. I noticed things were very wrong when I couldn't even open a simple xterm . I knew I was in trouble at that point

After rebooting I can still log in but the login gui does not come up but reverts to the standard xterm login. During the boot there is an error message stating that rhgb is looking for libxcb-xlib. Once logged in, startx also leads to errors (again xauth is looking for libxcb-xlib), eventhough typing X gives a grey screen and a usable mouse cursor. I looked in both /usr/lib & /usr/lib64 and it was missing (the other libxcb libraries are there). There are other problems like trying to run emacs -nw gives a libXrandr error, but I suspect that this is linked to the libxcb problem. If I use yum to reinstall libxcb.fc8.x86_64 it fails since it wants to install both FC11 and FC12 dependencies. Another problem is that I have also started to get rpmlib errors, occurring when I let yum try to install such dependencies (no real surprises there). Everything else seems to be working (ssh, networking etc)

So at this stage my main question is whether the system can be restored in a simple fashion or whether X is totalled and I should just do a new install to FC11 (after backing up about 2T of data)?

One thing I am thinking of trying is to somehow force yum look at the FC8 only archive and try to fix the Xwin system that way. Is this worth trying? If this fails, the next method is to try preupgrade . If this doesn't work then the obvious (clean install).

Any other ideas or suggestions would be greatly appreciated

Thanks in advance!

[CSchwangler]

I may be wrong but isn't the problem related to your Fedora version (FC8). As far as I know, and I may be totally wrong, Fedora 8 and 9 are out of support and their repositories are no longer maintained. That may be the reason why you now have dependency problems.
I am not sure that preupgrade is an option for you. I think with Fedora its only possible to go from one version to the immediate successor, e.g. F10 to F11. In your case you would upgrade from F8 to F11 and I thinks thats not possible with preupgrade.

[nicolang]

About the dependency issues ... I had figured that one out for myself. What I need to know is how to **fix it quick** with as little pain as possible. What would be good is to force/trick yum to look at one site only i.e. in Fedora's archives http://archive.fedoraproject.org/pub...64/os/Packages) for example. Then I hope the system can be resurrected to its former state.

As for preupgrade I took a look at http://fedoraproject.org/wiki/PreUpgrade which caught my attention. If preupgrade works without any issues that would be an excellent way to go from FC8 -> FC11.

Anyway, what's important is that I find a **possible** quick fix since I need to finish off some pending projects ASAP. If there is no possible way and all else fails then obviously its a new & time consuming install.

[Eps2Inf]

Forgive me if I'm stating the obvious... But why would you need to backup 2T of user data for a Fedora install? A methodical partitioning of your disk creates distinct filesystems that you can omit during a fresh install of Fedora (or any other Linux distro). I create different partitions for user data and programs (e.g., /home is mounted on /dev/sda5, /opt is mounted on /dev/sda6). Then, during a fresh install of the latest Fedora release (e.g. FC11 x86_64), I can reformat and load all filesystems, without touching [destroying] user data.

[user@localhost ~]$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 20161204 868208 18268856 5% /
/dev/sda6 20627668 189208 19390624 1% /opt
/dev/sda7 20161172 3859200 15277832 21% /usr
/dev/sda5 69436796 56400024 9452676 86% /home
tmpfs 986928 940 985988 1% /dev/shm

[CSchwangler]

Originally Posted by Eps2Inf

Forgive me if I'm stating the obvious... But why would you need to backup 2T of user data for a Fedora install? A methodical partitioning of your disk creates distinct filesystems that you can omit during a fresh install of Fedora (or any other Linux distro). I create different partitions for user data and programs (e.g., /home is mounted on /dev/sda5, /opt is mounted on /dev/sda6). Then, during a fresh install of the latest Fedora release (e.g. FC11 x86_64), I can reformat and load all filesystems, without touching [destroying] user data.

[user@localhost ~]$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 20161204 868208 18268856 5% /
/dev/sda6 20627668 189208 19390624 1% /opt
/dev/sda7 20161172 3859200 15277832 21% /usr
/dev/sda5 69436796 56400024 9452676 86% /home
tmpfs 986928 940 985988 1% /dev/shm

This is true but one must take care of old configuration files in /home directory, which may also be part of the problem. These should be deleted before the installation starts, e.g. out of a live cd session.

[nicolang]

Eps2Inf ... why I need to backup 2T worth of data ... 2 reasons ... The first is called "company policy". The SEs often remind you to "backup data". They drum this into you. The second reason is to make absolutely sure that I don't loose anything. The data comes from thousands of simulation that I DON'T want to repeat or regenerate. Better to be safe than sorry! In the past (many years ago) I have been in situations where new installs have gone horribly wrong and I had to start from scratch (minus data). Fortunately in those situations I had backups elsewhere.

By the way CSchwangler, do you mean configuration files found /etc or the ones in /home/<userx>/ directory (hidden files?). Are there any others places where these configuration files reside?

Anyway .. guys you haven't answered my question about restricting yum t to look in one place only? If this can be done then I think just reinstalling libxcb-xlib any other dependent libraries will do the trick.