In his message "SUMMARY: 4.0D/PK3 Kernel Build Problem" of "Tue, 09 Feb 99",
Alex Gorbachev <alex_at_iss-integration.com> commented:
> Ultimately, it turned out that the SCSI Media Changer subset 1.3
> installed _after_patch_kit 3 had messed up the kernel object files.
> Backing out patch kit, redoing installupdate (Many thanks to Dr. Tom
> Blinn for letting me know that this is possible), reinstalling all
> subsets and reapplying patch kit 3 solved the problem.
>
> I suppose, the gist of the matter is: do not install any subsets from the
> original media on top of a patch kit.
Here's the real problem:
Sometimes kernel layered product kits (like the SCSI Media Changer) contain
one or more files built from the original kernel sources that replace one or
more files from the original kernel build binaries. We here in the base OS
engineering group TRY VERY HARD to persuade the kernel layered product groups
that they should NEVER do this, because it can fail to work correctly if the
kernel layered product kit gets installed on an incompatible version of the
base OS software.
When the support engineering group works on patch kits, they start from the
same original kernel sources, but they may (and almost always do) replace some
of the original kernel build binaries with patched versions. The replacement
files MIGHT have interdependencies on one another, and the patch kits do lots
of checking to assure that ALL of the interdependent pieces are delivered in
the patch kit and are installed together. (Suffice it to say that building a
kernel is a complicated task, and because of the modular nature of the design
there are interdepencies that need to be considered. The Makefile is messy,
is generated "on the fly" based on a variety of information, and if there are
any inter-module references that aren't resolved, then the "ld" step fails.)
If a patch kit replaces the same kernel build binaries as part of a patch that
were (or will be) replaced by a kernel layered product kit, and there are any
incompatibilities between the replacements from the two different sources, it
is unlikely the kernel will build.
If the kernel does build, and the pieces are "mix and match", built from a set
of incompatible sources, then it's possible that the resulting kernel won't be
working exactly as expected. For example, if the SCSI Media Changer depends
on changes in kernel modules that were replaced by the patch kit, then it may
not function as expected.
Because the kernel layered products are built and released BEFORE the patches
are developed and delivered, there is obviously no way in advance for either
of the teams to assure that every possible kernel layered product will always
be compatible with the patched operating system, for every subsequent set of
patches.
I do not know exactly why the situation Alex reported occurred, but it brings
to light a problem that prudent managers will consider, which is that kernel
layered products (like the SCSI Media Changer) are usually built starting from
the same base OS sources that were used to build the patch kits, but they may
not be compatible with the operating system once the patches are installed.
So, a word to the wise: If you are going to patch a system that depends on
one or more kernel layered products for its correct operation, be careful how
you go about patching the system. Check the kernel layered product's set of
files (look in /usr/.smdb. for the ".inv" files that list the product's files
and look for things installed into the ./sys/BINARY directory, for example).
If you have to baseline the system to get the patches to install, then it is
likely that one or more of the kernel layered products on the system changed
one or more of the original base OS components. (Products can also change a
component outside the kernel build environment and cause the incompatibility
between the base OS inventory and the installed files that requires you to do
a "baseline" to get the patch kit to install.)
If you don't understand what is causing the incompatibilities, you can make
use of the "fverify" tool to compare the original subset inventories to the
installed files. "fverify" together with the installed subset inventory lists
in /usr/.smdb. can really be your friend. Read the "fverify" reference page
for more information.
Tom
Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation
110 Spit Brook Road, MS ZKO3-2/U20 Nashua, New Hampshire 03062-2698
Technology Partnership Engineering Phone: (603) 884-0646
Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb
ACM Member: tpblinn_at_acm.org PC_at_Home: tom_at_felines.mv.net
Worry kills more people than work because more people worry than work.
Keep your stick on the ice. -- Steve Smith ("Red Green")
My favorite palindrome is: Satan, oscillate my metallic sonatas.
-- Phil Agre, pagre_at_ucsd.edu
Yesterday it worked / Today it is not working / UNIX is like that
-- apologies to Margaret Segall
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
Received on Wed Feb 10 1999 - 13:25:29 NZDT