Description of problem: When executing rpm --rebuilddb (or any other switch which alters package database), libguestfs is exitting with an error. Version-Release number of selected component (if applicable): Host: [oddthesis@lolek-f11 ~]$ uname -a Linux lolek-f11 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun 16 23:19:53 EDT 2009 i686 i686 i386 GNU/Linux Guest: Same as host. [oddthesis@lolek-f11 downloads]$ rpm -qa | grep guestfs libguestfs-1.0.61-1.fc11.i586 libguestfs-java-1.0.61-1.fc11.i586 libguestfs-javadoc-1.0.61-1.fc11.i586 libguestfs-devel-1.0.61-1.fc11.i586 perl-libguestfs-1.0.61-1.fc11.i586 ocaml-libguestfs-1.0.61-1.fc11.i586 libguestfs-java-devel-1.0.61-1.fc11.i586 ruby-libguestfs-1.0.61-1.fc11.i586 libguestfs-debuginfo-1.0.61-1.fc11.i586 python-libguestfs-1.0.61-1.fc11.i586 How reproducible: Always. Steps to Reproduce: 1. Grab disk image from: http://repo.oddthesis.org/dev/management-appliance.raw.gz 2. Launch guestfish: guestfish -iv management-appliance.raw 3. Remove old db lock files: sh "rm /var/lib/rpm/__db.*" 4. Try to rebuild database: command "rpm --rebuilddb" Actual results: Different errors: - Error without information - rpm segfault in different libs - no vm86_info: BAD error Expected results: No error, RPM package database rebuild. Additional info: On 64 bit host (and guest), everything works great.
Output from guestfish: http://gist.github.com/150259
I can't reproduce this at all. I tried: - 32 bit w/ HVM - 32 bit w/o HVM - 64 bit w/ HVM - 64 bit w/o HVM and all worked perfectly. I don't have any guests running on VMWare ESX. Please try to reproduce this on a baremetal host. If it doesn't happen on a baremetal host, then it's a bug in VMWare, so you should ask VMWare to look at it. > - rpm segfault in different libs > - no vm86_info: BAD error Both of these errors indicate serious, random corruption in qemu's emulation (TCG in this case). Maybe VMWare can't run qemu correctly. Since it seems you have general problems running binaries in this configuration, I strongly suggest you use a binary such as /bin/false or: main () { exit (0); } and try to get that to fail, with a stacktrace, on a baremetal host. There are just too many variables when you're trying to run some process as complex as 'rpm --rebuilddb' to know where to begin.
I'm now convinced this is a dup of 502074. *** This bug has been marked as a duplicate of bug 502074 ***