You are not logged in.

#1 2007-10-08 21:25:29

android
Member
From: San Diego
Registered: 2003-04-18
Posts: 160

aspell upgrade leads to -> FATAL: kernel too old <- SYSTEM BACK UP 8-)

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)

Offline

#2 2007-10-09 11:16:37

JGC
Developer
Registered: 2003-12-03
Posts: 1,664

Re: aspell upgrade leads to -> FATAL: kernel too old <- SYSTEM BACK UP 8-)

As the message  says, your kernel is too old. glibc needs kernel 2.6.13 as minimum.You should have upgraded your system completely with pacman -Syu instead of picking selective packages and forcing upgrades.
You can still use pacman.static to install/upgrade/downgrade packages, but be aware that without a new kernel or an older glibc your system won't boot anymore.

Offline

#3 2007-10-10 04:53:47

android
Member
From: San Diego
Registered: 2003-04-18
Posts: 160

Re: aspell upgrade leads to -> FATAL: kernel too old <- SYSTEM BACK UP 8-)

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

Offline

#4 2007-10-10 07:01:38

shining
Pacman Developer
Registered: 2006-05-10
Posts: 2,043

Re: aspell upgrade leads to -> FATAL: kernel too old <- SYSTEM BACK UP 8-)

android wrote:

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.

You can just ignore that package on command line temporarily (see man pacman), or permanently put it in pacman.conf (man pacman.conf).

I looked at pacman -Si ttf-bitstream-vera (check the Conflicts). It looks like it doesn't conflict with xorg directly, but maybe it does indirectly.
If that's the case, you might be able to get the relevant informations from pacman --debug output.

Finally, afaik xorg was just a meta package (at least in the recent times. check pacman -Ql xorg output), and it has been removed not too long ago. It will be replaced by a xorg group with the new 7.3 release.
In any cases, you should be able to safely remove this metapackage.


pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))

Offline

Board footer

Powered by FluxBB