FC5t3 - rpm -e hangs up
Jim Cornette
fct-cornette at insight.rr.com
Sat Mar 4 05:17:36 UTC 2006
Jan Andrejkovic wrote:
> Hello Jim and everybody who is willing to help,
>
> Runlevel 1 did not help, but I have found the source of the problem,
> unfortunatelly not the solution:
>
> The source of the problem is that I have deleted some installed files
> manually, without RPM.
Not a good practice. This is not wise for any operating system. RPM does
a great job removing and installing files when the rpm file is properly
referenced for installation and removal of packages. Not all packages
are always setup correctly but the bulk of rpms are well thought out by
those that setup the routines that rpm undergoes. There are many options
that rpm can handle and many that I am still not familiar with after
years of usage.
> Anyway I think rpm should be robust and it should not hang if some files
> are deleted.
It depends upon which files that you deleted. If you deleted a common
file or a file which is intricate to the program's operation or that of
the system, it will have no choice but to bomb out. Its primary jobs are
to allow adding removing of programs in a sane manner, ensuring that the
program contains all its needed components (binaries, setup files,
services started, user added, and on) It can only do so if all of the
components are left intact.
Since rpm checks for files being in a location, missing or that the file
is not like the orginal, it does catch the most likely situations. But
if rpm checked every file for its presence before trying to remove a
file, it would require a longer time for rpm to complete the task of
adding or removing the files.
It sounds like you might have pressed rpm and the package that you were
trying to remove into a corner case and if you can recall what you
deleted, it might be helpful to prevent a future incident in the
package, rpm program or user awareness and familiarity with the program
concept.
> It should display some warning instead.
Granted, rpm should ideally use its feature for verifying everything is
present before attempting a package removal. It should at least check
for the file presence or have a routine to accomplish if the file was
missing. I believe most rpms are setup to continue or report the problem
to the terminal output if a problem was encountered.
There are problems that happen when failures happen with %post and %pre
scripts that need improvement in design. The major drawbacks are when
%pre scripts fail and programs are setup to be installed, they may not
ever install because deps are checked before the installation
transaction. Things seemed setup for the transaction to do the right
thing. The problem might be that the package is setup correctly, but
security programs may not grant permission to rpm to place files, run
tasks and other unpredictable problems.
The problem with %post script failures is that the tasks might be
completed pretty much and there was only a minor failure because the rpm
was on its cleanup phase. Other %post failures might cause operational
tasks from completing such as a kernel never getting through to the
portion where the image needed for the modules and the entry into the
bootloader never gets completed. I am sure that the packagers keep all
of these factors in mind and do their best to prevent problems from
occurring.
>
> I have used -vv option and here is deailed output from rpm:
> rm -f /var/lib/rpm/__db*
the deleted portion looks normal to me. I however never packages a
program for distribution.
> D: 0 0 0 3 1 0 -
> kernel-xenU-devel-2.6.13-1.1532_FC4.i686
> D: ========== successors only (0 bytes)
Those that know more about the workings of rpm would know what the six
variables represent. The display of the rpm output does reveal to me
something more than I previously knew about rpm internals. I take it
that the program found no previous version to act upon. I am only going
on the zero bytes feedback.
> D: 1 0 0 0 1 1
> -kernel-xen0-devel-2.6.12-1.1454_FC4.i686
> D: 2 0 0 1 1 2
> -kernel-xen0-devel-2.6.13-1.1532_FC4.i686
> D: 3 0 0 2 1 3
> -kernel-xenU-devel-2.6.12-1.1454_FC4.i686
It looks like the first of six digits is some counter (0,1,2,3)
> D: closed db index /var/lib/rpm/Pubkeys
> D: closed db index /var/lib/rpm/Requirename
> D: closed db index /var/lib/rpm/Name
> D: closed db index /var/lib/rpm/Packages
> D: closed db environment /var/lib/rpm/Packages
> D: opening db environment /var/lib/rpm/Packages joinenv
> D: opening db index /var/lib/rpm/Packages create mode=0x42
> D: mounted filesystems:
> D: i dev bsize bavail iavail mount point
> D: 0 0x00000307 1024 287812 167116 /
> D: 1 0x00000003 4096 0 -1 /proc
> D: 2 0x00000000 4096 0 -1 /sys
> D: 3 0x0000000a 4096 0 -1 /dev/pts
> D: 4 0x00000011 4096 64439 64438 /dev/shm
> D: 5 0x0000030c 1024 135546 99333 /home
> D: 6 0x0000030b 1024 397619 131519 /tmp
> D: 7 0x00000308 4096 260065 1462823 /usr
> D: 8 0x0000030a 4096 157409 285427 /var
> D: 9 0x00000013 4096 0 -1
> /proc/sys/fs/binfmt_misc
> D: 10 0x00000014 4096 0 -1
> /var/lib/nfs/rpc_pipefs
> D: 11 0x00000015 4096 0 -1 /net
> D: sanity checking 4 elements
Rpm and the package being acted upon are trying to be sane.
> D: running pre-transaction scripts
This I take is the %pre factor mentioned earlier. What do I need to do
before proceeding with the installation of the package?
> D: computing 24608 file fingerprints
> D: computing file dispositions
> D: opening db index /var/lib/rpm/Basenames create mode=0x42
> Killed
You might be able to use a program that can actually peek into the
actual package to see what the following step would be. There is a file
manager utility/shell program called mc (midnight commander) which is
able to dive into the rpm content. The script is executable so be sure
to use the F3 function key to view the file content. Being able to view
what is actually within a packages rpm might show interest to you and
enlighten you more than the link you referenced tries to explain.
I have used mc to view rpms and deb package content and found the
internals of both formats interesting. It is also possible to retrieve
files from the rpms, deb or whatever files with mc.
>
> It hanged after the last step and I had to kill it.
If the similarity is anything like DOS loading stuff, it is usually the
step following the lockup. It locked and did not reveal anything
regarding its initialization. Personally, I like feedback before
performing the function and feedback as to what the results were for the
tasks.
> I have straced it as well and here is the part of output from strace
> which is running in a neverending loop:
> <cut>
> stat64("/usr/src/kernels/2.6.12- 1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-
> 1.1454_FC4-xenU-i686/arch/i386/mach-visws", 0xbfbd6784) = -1 ENOENT (No
> such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386/mach-voyager",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386/math-emu",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386/mm",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386/oprofile",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386/pci",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch", 0xbfbd6784)
> = -1 ENOENT (No such file or directory)
> stat64("/usr/src/kernels/2.6.12-1.1454_FC4-xenU-i686/arch/i386/power",
> 0xbfbd6784) = -1 ENOENT (No such file or directory)
> <cut>
>
> I have deleted my FC4 xen kernels in FC5t3 manually because I thought
> that rpm dabase is already clear. I was wrong.
> My RPM version is: 4.4.2
>
> Do you think I should open bugzilla ticket?
It is a shortcoming of the package, not rpm to be able to handle this
circumstance. I file bug reports myself for the developer to at least be
aware of something that could be handled better. Most reports are marked
as not supported or the like. The awareness for the developer is at
least presented to the developer. Backburner or not, the rpm routine
should be able to handle this possible situation.
> Do you have any advice how can I reinstall my xen or what can I do?
rpm has features where you can ignore scripts, delete only the rpmdb
entry and a host of possible resolutions. Rpm most likely has features
which will get you out of the problem.
I would run
rpm -e --justdb --nodeps <continuous-loop-package>
and then try to *install* this rpm again if desired. By reviewing the
output above, running my favorite command above to rid the rpmdb entry
from the older version package should be enough. Reading your original
posting, it seems that you already attempted this feature.
>
> By the way I have found very good rpm guide, but it did not help me either:
> http://www.redhat.com/docs/books/max-rpm
I'll have to take a look at this page later myself. I never read the
documentation before.
>
> Thank you very much,
>
> Jan
>
> On 3/1/06, *Jim Cornette * <fct-cornette at insight.rr.com
> <mailto:fct-cornette at insight.rr.com>> wrote:
>
> Jan Andrejkovic wrote:
> > Hello,
> >
> > I have upgraded FC4 to FC5t3. I had some xen problems therefore I
> have
> > decided to reinstall xen packages.
> > But when I try
> > rpm -e kernel-xen-hypervisor-devel or rpm -e
> kernel-xen-guest-devel rpm
> > hangs up and eats almost 100% cpu for long time.
> > I need to use kill -9 to stop it.
Were you removing 1454 or 1532. If you have multiple versions installed,
specifying which version might be needed. RPM should have bombed out
specifying that multiple versions installed and to specify which version
that you wanted to remove.
> >
> > I have tried to do
> > rm -f /var/lib/rpm/__db*
> > and
> > rpm --rebuilddb
> > but nothing helped after those commands - it hangs again.
> >
> > I have also tried rpm -e --justdb but it did not help either.
Without specifying the version to remove? Or specifying which verson to
remove?
> >
>> Initially it was "yum remove" which hanged first. But as far as I
> know it uses rpm therefore I report this as rpm problem.
I have no idea for certain. I missed a lot of information from your
original posting as reference to the steps you tried.
>>
>> Does anybody have the same problem or can anybody tell me some
>> workaround how I can remove those packages manually and possibly
> rebuild database without them?
I believe the database does not need rebuilt. The entries within the
database need corrected by human intervention using the features rpm is
capable of.
I hope that I am not misleading or jumping off on unrelated to your
problem. I doubt that is the case though, I probably departed on several
issues. I was afraid to reply to the posting initially with all the
information provided in verbose and debugging output.
I'd figure out how best to represent the problem with yum and the
hypervisor removal and your actions. I believe you attempted using yum
then rpm and later deleted the files afterward. It sounds like a really
big bug since the looping and cpu utilization.
>>
>> Thank you very much,
>>
>> Jan
>
>
I hope this leads you to a resolution of the problem.
Jim
--
What I want is all of the power and none of the responsibility.
More information about the fedora-test-list
mailing list