[5928] in testers
Re: advansys.o kernel module missing
daemon@ATHENA.MIT.EDU (Bill Cattey)
Wed Jun 9 17:22:27 2004
From: Bill Cattey <wdc@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
Cc: Kevin Chen <kchen@mit.edu>, testers@mit.edu, rhe-release@mit.edu
In-Reply-To: <1086734924.1468.433.camel@egyptian-gods.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1086816142.8597.52.camel@tokata.mit.edu>
Mime-Version: 1.0
Date: Wed, 09 Jun 2004 17:22:23 -0400
Thanks for the clarification.
I swam around in bugzilla to learn more about kernel-unsupported.
As a consequence of that, I opened bug ID 125671 wherein I complain that
the concept of kernel-unsupported is broken. When nothing happens with
this bug, I'll complain through some back channels I have.
-wdc
On Tue, 2004-06-08 at 18:48, Greg Hudson wrote:
> On Tue, 2004-06-08 at 17:42, Bill Cattey wrote:
> > Could you clarify to me why we need to ensure that kernel-unsupported
> > installs before kernel? Should I be beating on Red Hat to offer this
> > functionality in that bug report?
>
> If a machine needs a kernel module to read the root filesystem (almost
> every machine does these days, since ext3 is built as a module instead
> of as part of the kernel itself), then each time the kernel is upgraded,
> a post-install script creates a bundle called an "initrd" which contains
> the necessary modules. The boot loader (grub or lilo) loads the initrd
> file as well as the kernel.
>
> To build the initrd file, the necessary kernel modules must be present
> in /lib/modules/<kernelversion>, where kernel-unsupported installs
> them. So if kernel-unsupported is not installed before kernel, the
> kernel RPM will fail to build the new initrd and the boot loader won't
> get updated. (And then the boot loader entry for the old kernel will
> get removed on account of the old kernel RPM being uninstalled, and the
> machine won't be able to boot Linux any more.)
>
> I have asked rpm-list for advice on solving the ordering problem without
> modifying the RPMs (for instance, depending on how the dependency order
> is computed, it might work to ensure that kernel-unsupported is added to
> the transaction set first). If that doesn't pan out, it would still
> make sense to add kernel-unsupported to the release for other reasons,
> but we'd have no practical way of ensuring that unsupported modules will
> work in an initrd.
>
> (Late realization: since kernel-unsupported has no dependencies of note
> and pretty much just drops a bunch of files in
> /lib/modules/<kernelvers>, we could install it in a separate rpmlib
> transaction from the rest of the upgrade. Ugly, but no uglier than
> putting it first in the transaction set. I'll work on a patch to do
> that.)
>
> Here is the argument I would make with Red Hat: Red Hat claims it is
> providing kernel-unsupported as a "courtesy" to its RHEL users, when in
> reality it has gone out of its way to separate these modules out from
> the main kernel RPM. It is being particularly discourteous to owners of
> machines which need one of these modules in an initrd, because there is
> no RPM dependency information to ensure that kernel-unsupported is
> upgraded before kernel during an upgrade of the kernel modules.
>
> Note that in Fedora Core, the main kernel RPM contains all the modules.
> So, as with the missing devel RPMs, this is a case where RHEL has value
> subtracted relative to the free product.
>
