As far as I can see there is no requirement in coreutils on the kernel version, directly or otherwise.

However even if there was, using requires/conflicts on a kernel version is almost always a bad idea because:

1. It's a feature that you can have more than one version of the kernel installed at once.

2. It's a feature that you can boot old versions of the kernel.

...this is somewhat offset by the fact you are moving from F-13 to F-14, but even then it's not unheard of for people to want to boot the old kernel.
 Anyway ... reassigning to coreutils, although I wouldn't be shocked if this was a Xen problem.

(In reply to comment #0)
> # /bin/true
> FATAL: kernel too old

There is no such message in coreutils.  It comes from glibc.

Moving to glibc as this is the package which should require newer kernel.

I don't think the problem is in glibc.
I think the problem is in yum or rpm.
glibc already conflicts with kernel < 2.6.32

# rpm -q --conflicts glibc-2.12.90-18.x86_64
kernel < 2.6.32
binutils < 2.19.51.0.10
prelink < 0.4.2

The problem is that even though there's a conflict with kernel < 2.6.32, this doesn't prevent yum/rpm from upgrading to this package while running kernel 2.6.26.

Basically yum/rpm should special case a kernel conflict to also conflict against uname -r

Note:

It is relatively common to have absolutely no control over the kernel on a Xen-based VPS, and be running whatever kernel was provided by the provider, and have the Fedora kernel package be merely installed as a placeholder.

ie.

# uname -r
2.6.32-domU-static

# rpm -q kernel
kernel-2.6.35.6-48.fc14.x86_64

On the above system upgrading to a glibc with conflict 'kernel < 2.6.35' will blow up spectacularly - the requirements are 'met' (there is no installed kernel rpm < 2.6.35), but after the install finishes absolutely _nothing_ works anymore (since the running kernel is < 2.6.35 and anything using glibc (ie. basically everything, including bash, true, yum, rpm) aborts with a "FATAL: kernel too old".

This is why I'm suggesting that rpm/yum should special case kernel conflicts to also check uname -r.  This would fix the above issue.

This needs to go over to rpm for input since it's the lower level - and people will see the same problem there.

thoughts on run-time-specific behavior for prcs?

Sure - there are cases where runtime dependencies are needed to correctly express package's requirements. Kernel is one of the more obvious ones but by no means the only one.

So yes, rpm should have a way of expressing runtime dependencies. Maybe it's about time it gets implemented too :)

Personally I don't see how taking things not in the rpmdb into consideration can end well, even in the case of just the kernel ... what happens with kmod requires?
Any "feature" that breaks --installroot, mock and possibly even plain updates seems like a really bad idea.

We could maybe get really special for just conflicts, and just on the kernel ... but I would bet $5 we'll get more bugreports after we do that change than before (but then, at this point we only need 2).
And even then, the real solution will still be "don't screw up backwards compat. in glibc" IMNSHO.

Of course runtime dependencies are special cases that should be few and far between. 

But it's not about breaking anything, it's about /preventing/ breakage: if updating to a newer glibc (or whatever) requires that you update and reboot to a newer kernel first to avoid a total system meltdown, we'd better be able to express that condition. Currently we can't. And if something fails to work in a chroot if hosted on too old a system, it's better to say so upfront than silently install broken garbage like we do now.

Realistically speaking "not being able to install something in a chroot because your running kernel is too old" is a _much_ lower problem then "being able to install a newer glibc in root" and then having a _totally_ and absolutely hosed system and being unable to even run bash, etc.

I'm willing to bet most people wouldn't be able to recover from a "glibc requires a kernel newer than any installed version" problem.  Not to mention that *most* of the installscriplets also failed as part of the upgrade (once glibc is upgraded all future installscriplets fail since bash won't run).  Even if you ctrl+c out of the upgrade when you notice this, it is already too late... the damage has already been done.

Besides, you can't even argue that installing in the chroot is not dependent on the running kernel version, since you won't be able to run install pre/post-scripts in the chroot (since the binaries won't run on too old a kernel)...

IMHO if your glibc (rpm) requires kernel 2.6.32, and you're running kernel 2.6.26 there isn't anyway you can really install that rpm besides gracefully bail.
You could of course have an rpm flag to override this safety check, but I'm not sure there's any sane use for it.

I can't think of any example that would make sense for kmod requirements to be treated specially like this.

> IMHO if your glibc (rpm) requires kernel 2.6.32, and you're running kernel
> 2.6.26 there isn't anyway you can really install that rpm besides gracefully
> bail.

 I do not disagree, but how much of this is a yum/rpm problem is debatable. One "problem" is that (at least historically) there has been a bigger effort to be backwards compat. in glibc so force upgrades of the kernel haven't been needed before.
 Indeed the only other case that comes close to this is rpmlib() additions, and although we've had a significant amount of those ... our best solution is still "don't do that".
 And kernels are even more special in that the kernel that is running when you do the upgrade isn't necessarily the one you'll have later on. So the problem will still exist, they'll just be less reason to blame yum/rpm.

> I can't think of any example that would make sense for kmod requirements to be
> treated specially like this.

kmod's have requires, often for specific kernel versions. If we apply those requires to the running kernel then, at best, mock/etc. will be broken and live systems will require horrid 3 stage upgrades.
Looking at the current kmod's none of them appear to have conflicts, but I'm very reticent to say that it'd be a good idea to have just conflicts on kernel packages be magic.

glibc-2.12.90-19 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/glibc-2.12.90-19

Here's the glibc change relevant to this bug:

diff -Naur 18/glibc.spec 19/glibc.spec 

with post-processing to keep only relevant changes.

@@ -862,6 +862,26 @@
 
+%pre -p <lua>
+-- Check that the running kernel is new enough
+required = '%{enablekernel}'
+f = io.open("/proc/sys/kernel/osrelease")
+if f then
+  rel = {}
+  for v in string.gmatch(f:read(), '%%d+') do
+    table.insert(rel, tonumber(v))
+  end
+  i = 1
+  for r in string.gmatch(required, '%%d+') do
+    if rel[i] == nil or tonumber(r) > rel[i] then
+      print("FATAL: kernel too old")
+      os.exit(1)
+    end
+    if tonumber(r) < rel[i] then break end
+    i = i + 1
+  end
+end
+
 %post -p /usr/sbin/glibc_post_upgrade.%{_target_cpu}
 
@@ -1024,6 +1044,26 @@
  %changelog
+* Fri Nov 12 2010 Andreas Schwab <schwab> - 2.12.90-19
+- Check that the running kernel is new enough (#649589)
+
 * Fri Oct 22 2010 Andreas Schwab <schwab> - 2.12.90-18

glibc-2.12.90-19 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update glibc'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/glibc-2.12.90-19

glibc-2.12.90-19 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.