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
my own, custom RedHat CDs which mainly include the updates accumulated on
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,
this no longer works. These RPMs get registered in the RPM database in the
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
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.
Steps to Reproduce:
1. rpm -qp --requires <package-file> | grep PayloadFilesHavePrefix
2. if the command returns a line like "rpmlib(PayloadFilesHavePrefix) <=
the installation of this RPM from the RedHat 6.2 CD installation routine
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
to figure out, what got installed and upgrade it or use the RedHat Network,
is often not possible (server has no internet connection) or cumbersome
has only ISDN connection and is under time pressure). Both solutions are
as the well working procedure (creating own, complete, bootable CDs) has
broken without any need.
This leads to servers without all updates installed and subsequently
Changing component to RPM.
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 ...
You didn't understandt the problem. There is a documented way to build a
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
routines. You can't simply upgrade them to "4.0.2", because they're linked into
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
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.
While I understand your unhappiness, there were definitely reasons for the
Support for a 6.2 installer procedure cannot be assumed simply because it's
the documentation applies only to the version of rpm released with 6.2, and the
is basically "Use rpm-3.0.4." if that makes you happy ...
Here, Here! I stongly agree that jbj has not understood the impact (or scope) of
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
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...
I still believe, that you do not or want not understand the problem that me and
firstname.lastname@example.org face. It is basically not possible to use an automated
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.
Calling me (or other Red Hat engineers) names is not gonna get you a fix.
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 == '.' && afn == '/') afn += 2;
if (bfn == '.' && bfn == '/') bfn += 2;
return strcmp(afn, bfn);
Great. But the installer (at least on my RH 6.2 CD image, downloaded from
not based on 3.0.5. Should I download a new 6.2 Image? The one on ftp.redhat.com
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
problem with the rpm program. There is only an rpm 3.0.3 and a 4.0.2, so I don't
your reference to 3.0.5
Try asking on <email@example.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
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...