Aspell upgrade leads to - FATAL: kernel too old - SYSTEM BACK UP 8-)

Question

OK, I really hosed it up now 8-(
Who would think that upgrading a spellchecker could cause such a problem, but upgrading aspell has totally crashed my system.
I knew something was fishy when it wanted to change all of the gcclibs, but I went ahead and --force 'd  the upgrade anyway. What a schmuck!
It brings something to mind about too much rope.
Now I can't run any command without it leading to -> FATAL: kernel too old
I can't pacman back to the older package, I can't manually cp the files, WTF?!
Seems like the kernel itself should have been a dependancy.
It looks like I'm rescue CD bound at this point.
Any insight as to what to repair first would be GREATLY appreciated.
The command line session that led to this little disaster is included below.
It's interesting that the programs that were already running will still run (the shell still runs, it just can't launch any new programs, even ls, mv, etc.) I'm even making this post from the browser that was running prior to the debacle, but I can't ls, wow.
Thanks again for any insight...
android
~~~~~~~~~~~~~~~~~ here's what happened ~~~~~~~~~~~~~~~~~~~~~~
root@recube johnea]# pacman -S aspell
resolving dependencies... done.
looking for inter-conflicts... done.
Targets: kernel-headers-2.6.22.1-1  glibc-2.6.1-2  gcc-libs-4.2.1-2  aspell-0.60.5-2
Total Package Size:   13.14 MB
Proceed with installation? [Y/n]
:: Retrieving packages from current...
kernel-headers           611.0K  435.1K/s 00:00:01 [####################################################] 100%
glibc                     10.6M  899.7K/s 00:00:12 [####################################################] 100%
gcc-libs                1079.3K  568.4K/s 00:00:02 [####################################################] 100%
:: Retrieving packages from extra...
aspell                   877.5K  508.8K/s 00:00:02 [####################################################] 100%
checking package integrity... done.
cleaning up... done.
(4/4) checking for file conflicts                   [####################################################] 100%
error: could not prepare transaction
error: failed to commit transaction (conflicting files)
gcc-libs: /usr/lib/libgcc_s.so exists in filesystem
gcc-libs: /usr/lib/libgcc_s.so.1 exists in filesystem
gcc-libs: /usr/lib/libgomp.a exists in filesystem
gcc-libs: /usr/lib/libgomp.so exists in filesystem
gcc-libs: /usr/lib/libgomp.so.1 exists in filesystem
gcc-libs: /usr/lib/libgomp.so.1.0.0 exists in filesystem
gcc-libs: /usr/lib/libgomp.spec exists in filesystem
gcc-libs: /usr/lib/libmudflap.a exists in filesystem
gcc-libs: /usr/lib/libmudflap.so exists in filesystem
gcc-libs: /usr/lib/libmudflap.so.0 exists in filesystem
gcc-libs: /usr/lib/libmudflap.so.0.0.0 exists in filesystem
gcc-libs: /usr/lib/libmudflapth.a exists in filesystem
gcc-libs: /usr/lib/libmudflapth.so exists in filesystem
gcc-libs: /usr/lib/libmudflapth.so.0 exists in filesystem
gcc-libs: /usr/lib/libmudflapth.so.0.0.0 exists in filesystem
gcc-libs: /usr/lib/libssp.a exists in filesystem
gcc-libs: /usr/lib/libssp.so exists in filesystem
gcc-libs: /usr/lib/libssp.so.0 exists in filesystem
gcc-libs: /usr/lib/libssp.so.0.0.0 exists in filesystem
gcc-libs: /usr/lib/libssp_nonshared.a exists in filesystem
gcc-libs: /usr/lib/libstdc++.a exists in filesystem
gcc-libs: /usr/lib/libstdc++.so exists in filesystem
gcc-libs: /usr/lib/libstdc++.so.6 exists in filesystem
gcc-libs: /usr/lib/libstdc++.so.6.0.9 exists in filesystem
gcc-libs: /usr/lib/libsupc++.a exists in filesystem
gcc-libs: /usr/share/locale/de/LC_MESSAGES/libstdc++.mo exists in filesystem
gcc-libs: /usr/share/locale/fr/LC_MESSAGES/libstdc++.mo exists in filesystem
errors occurred, no packages were upgraded.
[root@recube johnea]#
[root@recube johnea]# pacman -S --force aspell
resolving dependencies... done.
looking for inter-conflicts... done.
Targets: kernel-headers-2.6.22.1-1  glibc-2.6.1-2  gcc-libs-4.2.1-2  aspell-0.60.5-2
Total Package Size:   13.14 MB
Proceed with installation? [Y/n]
checking package integrity... done.
cleaning up... done.
(1/4) upgrading kernel-headers                      [####################################################] 100%
(2/4) upgrading glibc                               [####################################################] 100%
FATAL: kernel too old
(3/4) installing gcc-libs                           [####################################################] 100%
(4/4) upgrading aspell                              [####################################################] 100%
FATAL: kernel too old
FATAL: kernel too old
[root@recube johnea]# ls -l /var/cache/pacman/pkg/ | grep gcc
FATAL: kernel too old
FATAL: kernel too old
[root@recube johnea]# ls
FATAL: kernel too old
[root@recube johnea]# pacman
FATAL: kernel too old
[root@recube johnea]#
Last edited by android (2007-10-10 04:54:58)

Answer 1

Thanks JGC!
After booting from a rescue CD, I was able to pacman -U to the 2.5 version of glibc and the appropriate kernel-headers and now I'm back in action.
This machine was setup about 2 years ago. At that time I built my own kernel in order to get all of my motherboard features to work.
I've been running arch as my primary desktop workstation for almost 5 years now. I've never really had luck using the pacman -Su option. There always seems to be some inter dependency issue that prevents it from completing.
For instance, after recovering from this current dillema (and backing up my home/ 8-) I thought I'd abandon my custom kernel and launch forward into stock arch.
The pacman -Su led to this isssue:
:: ttf-bitstream-vera conflicts with xorg. Remove xorg? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: ttf-bitstream-vera: conflicts with xorg
Now, I don't have a package installed called ttf-bitstream-vera, but apparently pacman thinks I need it and I can't have it and xorg at the same time.
Some variant of this situation occurs each time I've tried to use the upgrade feature of pacman through the years.
Now I know some people have never reinstalled their systems from sctratch for years by continuously using pacman -Su and just staying up to date. But this just hasn't worked for me. Each time something goes wrong, sometimes leaving me with a system that takes days to get back into working order.
This current issue, while being inconvenient in having to use a rescue CD to recover, wasn't that hard to overcome. I've done pacman -U to older versions numerous times to get out of problems caused by upgrading a specific package. However when a complete system upgrade goes bad, it's very difficult to discover what has to be downgraded to get back to the working system.
But, I'm willing to try again.
Any insight into why the ttf-bitstream-vera package should conflict with xorg would be very much appreciated.
I'm looking into setting pacman.conf to prevent ttf-bitstream-vera from being loaded at all. This is my current workaround approach. Once everything is upgraded perhaps these fonts will load without error.
As usual, things aren't as simple as one might first suspect.
Thanks again for your help!
android