Bug 38537 - RedHat CD Update process leaves installation unusable
RedHat CD Update process leaves installation unusable
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-01 07:46 EDT by Henning Schmiedehausen
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-01 11:10:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Henning Schmiedehausen 2001-05-01 07:46:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-1t i686)


Since quite a while I use the process as described in the RedHat-CD Howto
to create
my own, custom RedHat CDs which mainly include the updates accumulated on 
ftp.redhat.com 

This worked fine for a very long time and I'm pretty happy with these CDs. 

Starting with the RPMs dating March 29 and beyond (gnorpm, ircii,
ucd-snmp-*),
this no longer works. These RPMs get registered in the RPM database in the
install
process but the files are never really written to the disk. I figured out,
that the reason
for this seems to be the fact that these RPMs are built internally with the
new RPM
4.x tool, as these report at rpm -ql --requires:

rpm -qp --requires ucd-snmp-4.1.1-3.i386.rpm
rpm >= 4.0.2
[...]
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

While the older RPMs from ftp.redhat.com do not report this. 

Reproducible: Always
Steps to Reproduce:
1. rpm -qp --requires <package-file>  | grep PayloadFilesHavePrefix
2. if the command returns a line like "rpmlib(PayloadFilesHavePrefix) <=
4.0-1"
   the installation of this RPM from the RedHat 6.2 CD installation routine
does not
   work

Actual Results:  RPMs do not get installed

Expected Results:  RPMs should be installed

When installing a new system, currently I'm forced to either use two CDs
and try
to figure out, what got installed and upgrade it or use the RedHat Network,
which
is often not possible (server has no internet connection) or cumbersome
(customer
has only ISDN connection and is under time pressure). Both solutions are
unacceptable
as the well working procedure (creating own, complete, bootable CDs) has
been
broken without any need.

This leads to servers without all updates installed and subsequently
security problems.
Comment 1 Brent Fox 2001-05-01 11:10:11 EDT
Changing component to RPM.
Comment 2 Jeff Johnson 2001-05-06 10:02:01 EDT
Yup, rpm-4.0 and later stores files in the payload with a leading './'
component, with a tracking dependency to insure that packages with
the leading './' are associated with an rpmlib that understands those
packages. As always, rpm refuses to install any file in the payload
that it doesn't know about, so your custom install process silently
skips all the files in the payload.

Upgrade to rpm-4.0.2 and the ucd-snmp packages compiled against
the rpm-4.0.2 rpmlib, both released as errata. Alternatively, do neither of
the above immediately, as there are no security implications in not
upgrading to rpm-4.0.2 compatible packages. However all packages
for Red Hat 7.x and above have a './' prefix in the payload, so you
will need to adjust your custom install accordingly ...
Comment 3 Henning Schmiedehausen 2001-05-06 11:54:22 EDT
You didn't understandt the problem. There is a documented way to build a
"current" RedHat
CD from the official release and the Upgrades from ftp.redhat.com.

If you do so and install from this CD; the resulting installed system is
unsusable because the
"new" RPMs are silently skipped in the installation process with the
anaconda-internal RPM
routines. You can't simply upgrade them to "4.0.2", because they're linked into
the anaconda
binary in the installation images on the CD.

I do know how to install a system from the release CD and then upgrade RPM by
RPM. That's
now what I want.

I currently use the 7.1 CD installation process to install my upgrade 6.2
systems. Not exactly
"by the book" but works for me.

I'm still unhappy that you broke a valid and well established upgrade path
without any need. There
is no reason not to build the newer RPMs with the 3.x RPM program.
Comment 4 Jeff Johnson 2001-05-06 12:40:44 EDT
While I understand your unhappiness, there were definitely reasons for the
change(s).
Support for a 6.2 installer procedure cannot be assumed simply because it's
documented, as
the documentation applies only to the version of rpm released with 6.2, and the
answer
is basically "Use rpm-3.0.4." if that makes you happy ...
Comment 5 Cris 2001-06-07 01:15:44 EDT
Here, Here! I stongly agree that jbj has not understood the impact (or scope) of
this problem.

We have an automated kickstart server maintaince system, which merges changes
from 6.2/updates into the base redhat 6.2 build, along with local updates such
as openssh etc, by removing duplicate old versions of rpms and running
genhdlist.

We kickstart many systems from this server, which has basically suddenly broken
because, although the rpms are added OK by genhdlist, the rpm binary in the
install image fails to actually install the files (without errors).

We have a very cut down install (security application), so we we're only
seriously affected by the recent mgetty, mktemp releases - we don't care about
netscape-communicator etc., but its now a *serious high impact problem* - we are
now reduced to manually updating any rpms released after march 29th, so we can't
do an unattended install - which is very painful on our headless, keyboardless,
cdrom-less 1RU boxes.

The fix is either to rebuild the rpms so that they are still compatible with the
old installer (haha, no bloody chance) or issue a new install-image (boot.img,
bootnet.img) which understands the 'new' rpm format OK and doesn't mess up.

The rpm-4.0.x update is no use at install time - its not in the image. Will rpm
3.0.5 do the job? I don't know - the response to another bugzilla reporting a
variation of this problem suggested the user go to some unreleased cvs branch of
rpm, hack up the code to make it back compatible and re-roll his own install
images. Very Helpful.

This is not a CLOSED issue...
Comment 6 Henning Schmiedehausen 2001-06-07 05:04:45 EDT
Dear jbj,

I still believe, that you do not or want not understand the problem that me and
c.bailiff@devsecure.com face. It is basically not possible to use an automated
install any
longer without much handwork. 

Why is it not possible to build the upgrades to the 6.2. installation with the
3.0.x RPM? Just because
you're lazy or are there _real_ reasons for this? Or is it just that your
automated build process
just doesn't support it? It was possible up to March 29th, wasn't it?

Your blatant answer "use rpm-3.0.4" shows me, that you do not understand the
issue at all. The
problem is not the installed rpm program . The problem is the integrated RPM
installation routine in the anaconda installer. That's why I opened this ticket
with "installer", but someone moved it to
RPM where it is IMHO plain wrong.

Jeez, I do not understand, how thick headed RH engineers can be.

Comment 7 Jeff Johnson 2001-06-07 09:04:10 EDT
Calling me (or other Red Hat engineers) names is not gonna get you a fix.
(shrug)

rpm-3.0.5 and later should drop in, and will understand v4 packaging with
archives with a leading ./ just fine.

The other piece that needs to be fixed is to check that the copy
pf cpioFileMapCmp that was swiped and stashed in the installer
somewhere is idntical to the version in rpm-3.0.5:

int cpioFileMapCmp(const void * a, const void * b)
{
    const char * afn = ((const struct cpioFileMapping *)a)->archivePath;
    const char * bfn = ((const struct cpioFileMapping *)b)->archivePath;

    /* Match payloads with ./ prefixes as well. */
    if (afn[0] == '.' && afn[1] == '/') afn += 2;
    if (bfn[0] == '.' && bfn[1] == '/') bfn += 2;

    return strcmp(afn, bfn);
}
Comment 8 Henning Schmiedehausen 2001-06-07 10:36:37 EDT
Great. But the installer (at least on my RH 6.2 CD image, downloaded from
ftp.redhat.com) is
not based on 3.0.5. Should I download a new 6.2 Image? The one on ftp.redhat.com
has
Mar 9, 2001 as date, my master copy is much older (from somewhere in 2000).

Do you rebuild these images, shall I get a new one?

I apologize for the "thick headed". I was frustrated, that you seemed to mix the
installer
problem with the rpm program. There is only an rpm 3.0.3 and a 4.0.2, so I don't
understand
your reference to 3.0.5
Comment 9 Jeff Johnson 2001-06-09 07:32:49 EDT
Try asking on <rpm-list@redhat.com>. Several people have built
6.2 installers with rpm-3.0.5 successfully AFAIK.

Dunno whether Red Hat is gonna produce a new build, as there's
a fair amount of work after compiling to insure that everything
works ...
Comment 10 Cris 2001-07-24 23:43:32 EDT
How can this bug get closed with 'WORKSFORME' - it obviously remains broken.

jbj says thats its a fair amount of work after compiling to insure that
everything works OK. Thats for Redhat! How are we end users, who aren't RPM
developers, going to manage that?

I've done a hell of a lot of rpm building before, and I haven't a clue where to
begin. I could surely build rpm-3.0.5,6,7 given a week or so, but now I have to
learn how to build install disks from scratch, and make sure I put my version of
RPM in the right place somehow, and test it etc. 

If I spend a couple of weeks on this, it *might* solve my problem. What about
all the other poor suckers out there stuck in the same position. This is biting
us *big time* now - we can't move to rh7/7.1 because our commercial apps are
still stuck at 6.2 - I thought redhat wanted commercial apps to run on linux,
but it seems that 6.2 support has basically stopped already. Some O/S stability.

Guess we'll try mandrake next...

Note You need to log in before you can comment on or make changes to this bug.