[pacman-dev] "FATAL: kernel too old" error message during upgrade
Hi! One of our local community members is getting this output when doing -Syu after installing 0.7.2: checking package integrity... done. cleaning up... done. (8/8) checking for file conflicts [#####################] 100% (1/8) installing kernel-headers [#####################] 100% (2/8) upgrading glibc [#####################] 100% FATAL: kernel too old (3/8) installing binutils [#####################] 100% (4/8) installing gcc [#####################] 100% (5/8) installing db [#####################] 100% (6/8) installing gdbm [#####################] 100% (7/8) upgrading openssl [#####################] 100% (8/8) installing python [#####################] 100% FATAL: kernel too old FATAL: kernel too old Any ideas what causes this? -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
Hi!
One of our local community members is getting this output when doing -Syu after installing 0.7.2:
checking package integrity... done. cleaning up... done. (8/8) checking for file conflicts [#####################] 100% (1/8) installing kernel-headers [#####################] 100% (2/8) upgrading glibc [#####################] 100% FATAL: kernel too old (3/8) installing binutils [#####################] 100% (4/8) installing gcc [#####################] 100% (5/8) installing db [#####################] 100% (6/8) installing gdbm [#####################] 100% (7/8) upgrading openssl [#####################] 100% (8/8) installing python [#####################] 100% FATAL: kernel too old FATAL: kernel too old
Any ideas what causes this?
Glibc in 0.7.2 was compiled with --enable-kernel=2.4.1 (only supports kernels >= 2.4.1), current glibc is compile with --enable-kernel=2.6.13 (only supports kernels >= 2.6.13). So my guess is the user has a kernel older than 2.6.13. pacman -S kernel then pacman -Su should fix it. Andrew
2007/8/17, Andrew Fyfe
Roman Kyrylych wrote:
Hi!
One of our local community members is getting this output when doing -Syu after installing 0.7.2:
checking package integrity... done. cleaning up... done. (8/8) checking for file conflicts [#####################] 100% (1/8) installing kernel-headers [#####################] 100% (2/8) upgrading glibc [#####################] 100% FATAL: kernel too old (3/8) installing binutils [#####################] 100% (4/8) installing gcc [#####################] 100% (5/8) installing db [#####################] 100% (6/8) installing gdbm [#####################] 100% (7/8) upgrading openssl [#####################] 100% (8/8) installing python [#####################] 100% FATAL: kernel too old FATAL: kernel too old
Any ideas what causes this?
Glibc in 0.7.2 was compiled with --enable-kernel=2.4.1 (only supports kernels >= 2.4.1), current glibc is compile with --enable-kernel=2.6.13 (only supports kernels >= 2.6.13). So my guess is the user has a kernel older than 2.6.13. pacman -S kernel then pacman -Su should fix it.
Thanks! Didn't know about that. Hmm, as I see here: ftp://archlinux.org/archive/pkgs/0.7.2/os/i686/ 0.7.2 contained these kernel packages: kernel24-2.4.32-1 kernel24-scsi-2.4.32-1 kernel26-2.6.16.18-1 I ask him about kernel. -- Roman Kyrylych (Роман Кирилич)
Hi! I think this problem is serious and we should avoid these critical errors (I also had a glibc error with kernel 2.4 a few years ago). This error cannot be determined automatically by pacman (local db, depends...); so some extra packager work is needed. However, as I know there is no way to do some specific checks now before a package install... A possible solution: we should check the return value of pre-install script (or any other "communication channel" can be implemented), which could abort the install (I imagine an uname test in the script, and a nice question/error message to the user, and return 1 here). Bye, ngaba PS: Or we could implement a new scriptlet type, e.g. extra-depends. (This will lead to one of my earlier question (see fileconflicts): what to do if we have to stop the transaction after some packages installed and some other packages are waiting for install yet. So it is better to define extra-depends (similar to the normal depends) as a "pre-transaction argument".) ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Hi!
I think this problem is serious and we should avoid these critical errors (I also had a glibc error with kernel 2.4 a few years ago). This error cannot be determined automatically by pacman (local db, depends...); so some extra packager work is needed. However, as I know there is no way to do some specific checks now before a package install... A possible solution: we should check the return value of pre-install script (or any other "communication channel" can be implemented), which could abort the install (I imagine an uname test in the script, and a nice question/error message to the user, and return 1 here).
Bye, ngaba
PS: Or we could implement a new scriptlet type, e.g. extra-depends. (This will lead to one of my earlier question (see fileconflicts): what to do if we have to stop the transaction after some packages installed and some other packages are waiting for install yet. So it is better to define extra-depends (similar to the normal depends) as a "pre-transaction argument".)
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev This can be solved by adding a dep for kernel>=x.y.z to glibc, and add a
Nagy Gabor wrote: provide=('kernel') to all kernel images. Andrew
This can be solved by adding a dep for kernel>=x.y.z to glibc, and add a provide=('kernel') to all kernel images. Many users (like me) use custom kernel (and too lazy to create an arch package :-P). And provision doesn't work here, since we can't handle versioned provisions (yet). Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
This can be solved by adding a dep for kernel>=x.y.z to glibc, and add a provide=('kernel') to all kernel images. One more thing I must mention, this is not a dependency problem, this is mainly a "runtime" problem: pacman -S glibc will update kernel, if needed, but after glibc update the system becomes broken immediately (because the running kernel is still too old.) Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
participants (3)
-
Andrew Fyfe
-
Nagy Gabor
-
Roman Kyrylych