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.
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 "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.
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 ...
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...
Dear jbj, I still believe, that you do not or want not understand the problem that me and c.bailiff 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.
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); }
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
Try asking on <rpm-list>. 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 ...
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...