Re: FC5t3 - rpm -e hangs up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx <mailto:fct-cornette@xxxxxxxxxxxxxx>> 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.

--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]