A minor nit: I haven't updated my kernel recently, but did so last night in order to get iotop to work.
Sometime in the past year, or at least since 126.96.36.199 (see how far behind I was?), the packaging of the Modules tar file has been changed set the group write flag on all directories touched, which includes /, /lib, /lib/modules, etc. Since the ownership of these directories are all root/root, this does not present a security problem. However, the changing of the permissions on / (the root directory) breaks sendmail, which by default requires all its sensitive directories to not be group writeable. Thus, it breaks mail delivery.
Would it be possible to change future kernel loads so as to avoid setting group write permission on these directories?
BTW, 188.8.131.52 seemingly works fine in other respects. Now, iotop works for me, and I have noticed no other anomalies. I do wonder, though: Just how far can I push things as far as running the latest kernels on a Ubuntu 9.04 load? When will things start to break? (I suppose I mean, when will the kernel/user interface start to change? Does it only do so on major generic boundaries, such as the transition from 2.6 to 2.7?)
And, thanks again, cbxbiker61, for your continuing kernel support.
Glad you spotted the directory permission issue. It must be a quirk in "make modules_install". Anyway, it's an easy fix in my build script.
A 2.6.x to 2.7.x transition would pretty much imply that they're breaking some form of backwards compatibility.
As far as 2.6.x compatibilty goes. For the most part we're safe. Theoretically, the only time that backwards compatibility breaks is when they take a "deprecated" feature out, possibly to eliminate cruft in the /proc tree for example. By the time they do that though, most of the programs that have used that feature can be rebuilt to use the replacement features. Which mostly means recompiling the programs in question.