Red Hat Bugzilla – Bug 489235
rpm installs packages but skips all content if %_install_langs is set
Last modified: 2009-03-12 10:27:40 EDT
Description of problem:
Due to yum bailing out in the middle of a transaction I ended up with a number of damaged packages. For example:
# rpm -V upstart
.......T. c /etc/event.d/logd
.......T. d /usr/share/man/man5/events.5.gz
.......T. d /usr/share/man/man8/initctl.8.gz
.......T. d /usr/share/man/man8/logd.8.gz
.......T. d /usr/share/man/man8/runlevel.8.gz
.......T. d /usr/share/man/man8/shutdown.8.gz
.......T. d /usr/share/man/man8/telinit.8.gz
After 'rpm -Uvh --force upstart-0.3.9-22.fc11.x86_64.rpm' repeated
verification shows exactly the same output as above. Indeed /sbin/init,
for example, should be "135736 Mar 7 16:37" but despite a success from rpm
is still "138312 2009-01-23 18:05" and what was missing is missing.
With other packages one can get, for example:
1:cpp ########################################### [100%]
install-info: No such file or directory for /usr/share/info/cpp.info.gz
as missing /usr/share/info/cpp.info.gz is still missing. Other postinstall scriptlets are failing because required executables are not there.
To get around the issue I had to do, for all affected packages,
rpm2cpio package.rpm | (cd / && cpio -imd)
followed by a reinstallation to run scripts. Only after that verifications got silent.
Version-Release number of selected component (if applicable):
none of damaged packages was fixed by a reinstallation
See https://bugzilla.redhat.com/attachment.cgi?id=334455 attached to bug 489238 for details of failed verifications of newly "installed" packages.
Hm, what was really installed at all???
> Hm, what was really installed at all???
OK. So I tried the following safe experiment:
rpm -e fedora-release-notes
rpm -Uvh fedora-release-notes-10.0.0-1.noarch.rpm
After that every single file from that package is missing. What gives? Running with -vvv shows "skipnstate" flag for every file and directory. Does that mean what I guess it may mean?
Tar up the rpmdb and attach here please.
> OK. So I tried the following safe experiment:
> rpm -e fedora-release-notes
> rpm -Uvh fedora-release-notes-10.0.0-1.noarch.rpm
> After that every single file from that package is missing. What gives? Running
> with -vvv shows "skipnstate" flag for every file and directory. Does that mean
> what I guess it may mean?
I can confirm this bug, both on x86_64 and i586. After upgrade from rpm 4.6 to rpm 4.7 beta, all packages that I install using rpm (or yum, which uses librpm i guess) *seem* to be installed, but no files are put in the filesystem.
Tar up the rpmdb and attach here please. Also a log of rpm -Uvv / -evv of a case where it doesn't actually do anything would be useful.
Once you have backed up the rpmdb: does 'rpm --rebuilddb' clear up the situation?
> I can confirm this bug, both on x86_64 and i586. After upgrade from rpm 4.6 to
> rpm 4.7 beta, all packages that I install using rpm (or yum, which uses librpm
> i guess) *seem* to be installed, but no files are put in the filesystem.
There was a related problem long time ago:
It turns out that if I remove my /etc/rpm/macros file, RPM behaves again.
I have the following in the /etc/rpm/macros file to prevent installation of unnecessary i18n/l10n files:
Adding "C" locale to the _install_langs does not help. rpm 4.6 (and previous versions as well) worked without problems.
Yup, just noticed noticed it too: %_install_langs is broken in the beta. No need to attach rpmdbs or other logs as I now have a nice reproducer for it. Will fix shortly, in the meantime just comment out %_install_langs in configuration.
Created attachment 334483 [details]
Log of package installation, rpm 4.7, no files are installed (the files have skipnstate flag). This is with _install_langs set to "cs_CZ.UTF-8:cs_CZ:cs:en_US.UTF-8:en_US:en".
Created attachment 334485 [details]
Log of package installation, rpm 4.7, files successfully installed (the files don't have the skipnstate flag anymore). This is without _install_langs set.
Okay, should be fixed in rpm-4.7.0-0.beta1.3.fc11.
Leaving this open for a while in case somebody else happens to hit it before next rawhide push.
> Okay, should be fixed in rpm-4.7.0-0.beta1.3.fc11.
AFAICS this indeed does solve the issue. Thanks!
If affected by that bug one needs to be careful how this new rpm version is installed not to leave oneself without rpm executables. :-)
Ok, considering this done then.
*** Bug 489720 has been marked as a duplicate of this bug. ***