[5921] in testers
Re: advansys.o kernel module missing
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 8 18:48:47 2004
From: Greg Hudson <ghudson@MIT.EDU>
To: Bill Cattey <wdc@mit.edu>
Cc: Kevin Chen <kchen@mit.edu>, testers@mit.edu
In-Reply-To: <1086730966.18654.271.camel@tokata.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1086734924.1468.433.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
Date: Tue, 08 Jun 2004 18:48:44 -0400
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.
