From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030712 Description of problem: Previously done an upgrade from RH9 to RH9.0.93 without problem. That was originally a full install, and the upgrade went well. I then tried to upgrade a machine that had been installed with most, but not all packages. (In fact, I believe KDE was *not* installed...see below) Upgrade consistently aborts shortly after putting in 2nd CD. (Verified...it's okay!!) It *always* aborts on: kdebase-3.1.2-13. Error message suggests media failure (no) or diskspace (don't think so) or hardware (no). Note: free space at beginning of install was 2.5 GB Going to a "text" console, I saw the message: using kdebase-6:3.1.2-13.i386 to satisfy kdebase-6:3.1.2. Also, saw message: isys.py:mount() - going to mount /tmp/hdc on /mnt/source. NOTE: df -k shows allocation of 661056 blocks, 661056 used. Finally, the following is the text from /root/upgrade.log: Upgrading 227 packages The following packages were automatically selected to be installed: Upgrade: XFree86 was on the system. Pulling in xterm for upgrade. Upgrading compat-db-4.0.14-2.i386. Upgrading kdebase-3.1.2-13.i386. warning: /etc/X11/gdm/Sessions/KDE created as /etc/X11/gdm/Sessions/KDE.rpmnew warning: /etc/X11/xdm/kdmrc saved as /etc/X11/xdm/kdmrc.rpmorig warning: /etc/kderc saved as /etc/kderc.rpmorig warning: /etc/ksysguarddrc created as /etc/ksysguarddrc.rpmnew warning: /etc/pam.d/kde created as /etc/pam.d/kde.rpmnew error: unpacking of archive failed on file /usr/share/applnk-redhat: cpio: rename I have tried this at least 1/2 dozen times. Fails every time. Version-Release number of selected component (if applicable): 9.0.93 How reproducible: Always Steps to Reproduce: Fails when doing upgrade from RH9 to RH9.0.93. HOWEVER, upgrade on another machine worked flawlessly. Actual Results: Machine aborts install. At that point, it *thinks* it has upgraded to 9.0.93. But, a large number of packages are NOT upgraded. Expected Results: All packages on machine should have been upgraded. Additional info: I am puzzled why there is an attempt to install KDE base. When I do an rpm query, KDE is NOT installed to begin with. Perhaps it is required for something else. But, I am NOT a KDE user, don't install it when I am selecting packages, and yet it crashes on an attempt to install KDE base.
it looks like that /usr/share/applnk-redhat is a directory on your machine! Is it? It should be a symlink otherwise rpm will fail on upgrade!
Here is some additional information: After I posting the original bug report, I noticed that the "update" icon on the machine with the "update failure" was red. Sure enough, it reported that my system was NOT up-to-date....needed something like 200+ packages to upgrade. (Note...my machine got enough of the upgrade finished that it now "thinks" it is a 9.0.93 machine). Anyway, I downloaded *all* the packages, and then began the install process. It CRASHED during the install process with the following error: "There was a fatal RPM error. Unpack error installing the package KDEBASE-3.1.2-13." NOTE: When I tried to upgrade from disk, the upgrade crashed on this identical package. I am guessing, but I think the kdebase-3.1.2-13 package is corrupt and needs to be repackaged.
I just saw your note: "it looks like that /usr/share/applnk-redhat is a directory on your machine! Is it?" I'll follow-up this evening (machine is at home) and report. Oh...I should ask...if it should be a link, what should it be linked to?... Terry
it should be a link to ../../var/lib/menu/kde/Applications
I'll make the change tonight and let you know what happens.
This problem will be fixed if you remove the directory /usr/share/applnk-redhat and make a symlink to ../../var/lib/menu/kde/Applications. It should work. I don't know how it could happen on your machine, because the kdebase includes it as a symlink, not a directory!
I made the change you suggested. Re-named the directory to something else (to save it...just in case), and created the link. The upgrade went flawlessly at that point. All of which now creates the question of why a "hard" directory was created, and how it got created, rather than the link. I can tell you that this particular machine goes back a couple of generations in terms of an original installation. Everything since then has been handled as an upgrade. (Which includes betas prior to Release 9.) I can also assure you that I have never fooled around in this particular portion of the directory structure. So, at some point something got clobbered. But, again, not through direct human intervention. (I am the only person who uses and can access this particular machine). I will note that the package that the install originally crashed on (kdebase- 3.1.2-13.i386) was apparently being installed as a pre-req for something else. I don't know exactly what that "something else" was, and not sure if it makes any difference. But, I pass along the information. Thank you for your assistance. You solved MY problem. I suppose the larger issue is whether this type of issue gets reported on other machines.