Description of problem: When upgrading Mageia inside OpenVZ container with older kernel the glibc gets updated and then all commands generate "FATAL: kernel too old" message leading to completely unusable system. It would be nice when upgrading to check if required kernel version is available first before trying to upgrade glibc and other packages. Version-Release number of selected component (if applicable): Mageia 2 How reproducible: Always if kernel for Open VZ container is old enough Steps to Reproduce: 1. Create mageia1 (or mandriva) inside a OpenVZ container with kernel 2.6.18 2. Try to upgrade with CLI upgrade process (using urpmi --replacefiles --auto-update --auto) 3. Observe: core packages including glibc are upgraded and in the process "FATAL: kernel too old" message starts to appear; when urpmi exists nothing can be started due to kernel incompatibility with glibc Should be: when uprmi is about to upgrade glibc check if require kernel version is available On one side it's Critical: system will be completely unusable, on the other hand it's Enhancement: only happening within older containers, so I'm leaving Severity at Normal :)
so the only bug here is ? >It would be nice when upgrading to check if required kernel version is >available first before trying to upgrade glibc and other packages.
Source RPM: (none) => urpmi
Not checking the required kernel version when upgrading glibc and thus leaving system completely unusable. > so the only bug here is ?
Summary: Upgrading Mageia inside OpenVZ container with older kernel may corrupt the system => urpmi should check if the kernel and glibc version are coherent
That's not an urpmi bug. If glibc bumps minimal kernel required w/o giving hint (such as "provides: need-kernel-2.6.33"), there's nothing urpmi can do. It cannot magically known the minimum requirements of glibc. What's more you're using a kernel neither provided nor supported by mageia...
CC: (none) => thierry.vignaud, tmbSource RPM: urpmi => (none)
Closing
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
Hmm. I am hitting the same message when trying to install a clean version of Mageia 2 using the chroot + urpmi method from an existing Mandriva system. $ urpmi --urpmi-root /chroot basesystem urpmi locales-en Preparing... 1/6: dash-static 2/6: glibc FATAL: kernel too old error: %post(glibc-6:2.14.1-8.mga2.x86_64) scriptlet failed, signal 11 3/6: lib64termcap2 4/6: bash 5/6: lib64ncurses5 6/6: ncurses FATAL: kernel too old You should restart system for glibc Does it really matter what kernel version I'm running, since glibc and everything else is being installed on a chroot partition for later booting?
Status: RESOLVED => REOPENEDCC: (none) => eamerrittResolution: WONTFIX => (none)
Assignee: bugsquad => tmbSource RPM: (none) => glibc
To be absolutely clear - My problem is in a sense the opposite of the original bug report. There is no harm to the existing system (nothing is being installed on the active partition). The failure results from over-zealous version checking rather than omission of an early version check. I realize that due to the glibc mismatch I may not be able to actually chroot to the new installation and run the newly installed packages using the host kernel. But that's not the intent. I want to install a complete new system and then boot it. I have previously gone through the same steps successfully on another Mandriva machine, but this one is an older installation. I assume that installing from a DVD would bypass this issue, but it's a server at a remote location and has no dedicated DVD drive; installation via urpmi and a redirected root would be much more convenient. The Mageia wiki says "urpmi since urpmi-4.9.5, allows you to install any version of Mageia in a chroot without modifying the urpmi configuration of your running system". In my case the running system has urpmi 6.25.6, so I thought I was OK. Nothing is mentioned about kernel version requirements.
Whereis this is right, I lower the priority & severity since it cannot happen on most usages (as even mga1 main kernel is new enough)
Priority: Normal => LowSeverity: normal => minor
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: REOPENED => RESOLVEDResolution: (none) => OLD