Re: [Libguestfs] [PATCH] convert_linux: translate the first CD-ROM's references in boot conf files

On 12/15/21 16:34, Richard W.M. Jones wrote: > On Wed, Dec 15, 2021 at 03:33:00PM +0000, Richard W.M. Jones wrote: >> On Wed, Dec 15, 2021 at 04:14:42PM +0100, Laszlo Ersek wrote: >>> Before posting v2, I intended to test it :) , so I installed a new RHEL5 guest, and tried to run virt-v2v (with the v2 patch) on it: >>> >>> virt-v2v -i libvirt -o local -os ~/output rhel5.11 >> >> As a general comment, you might want to check virt-v2v 1.44 branch to >> see if these problems are regressions in virt-v2v or something else. >> >> In this case ... >> >>> Unfortunately, things break before my code gets a chance to run; here: >>> >>> (* Fail early if i_apps is empty. Certain steps such as kernel >>> * detection won't work without this. If the list is empty it >>> * likely indicates that libguestfs inspection is broken for >>> * this guest. See for example RHBZ#1965147. >>> *) >>> if inspect.i_apps = [] then >>> error (f_"inspection of the package database failed for ... >>> >>> This seems to come from an empty apps list, from "convert/inspect_source.ml", which in turn invokes "g#inspect_list_applications2". >>> >>> I turned to guestfish, and ran the following manually: >>> >>> inspect-os >>> inspect-get-mountpoints /dev/VolGroup00/LogVol00 >>> inspect-list-applications2 /dev/VolGroup00/LogVol00 >>> >>> Indeed the last command does not return anything. I turned on "verbose" and "trace" then, and then I see a failure in the daemon: >>> >>> libguestfs: trace: inspect_list_applications2 "/dev/VolGroup00/LogVol00" >>> libguestfs: trace: inspect_get_type "/dev/VolGroup00/LogVol00" >>> libguestfs: trace: inspect_get_type = "linux" >>> libguestfs: trace: inspect_get_package_format "/dev/VolGroup00/LogVol00" >>> libguestfs: trace: inspect_get_package_format = "rpm" >>> libguestfs: trace: internal_list_rpm_applications >>> \x1b[31;1merror: \x1b[0m\x1b[1mUnable to open /usr/lib/rpm/rpmrc for reading: No such file or directory. >>> \x1b[0m\x1b[31;1merror: \x1b[0m\x1b[1mno dbpath has been set >>> \x1b[0m\x1b[31;1merror: \x1b[0m\x1b[1mcannot open Packages database in >>> \x1b[0mlibrpm returned 0 installed packages >>> libguestfs: trace: internal_list_rpm_applications = <struct guestfs_application2_list(0)> >>> libguestfs: trace: inspect_list_applications2 = <struct guestfs_application2_list(0)> >> >> ... I think this is potentially an instance of: >> >> [sorry, BZ is down - I will follow up with the bug number] > > https://bugzilla.redhat.com/show_bug.cgi?id=1965147 Yep, that's exactly the BZ number that's highlighted in the code comment above. I had read the BZ quickly before posting my findings. However, the RPM error messages in the BZ are different. (I can't open the BZ ticket again because bugzilla is down (yay!), but I seem to remember that the librpm complaints were not about failures to open existent files. I could be wrong though, from memory.) Anyway, I guess this indicates that my Fedora 34 host does not have a recent enough librpm (and so the appliance too has an out-of-date librpm).

Thanks, Laszlo > >> The new thing here (not really related to virt-v2v) is that RPM itself >> changed from Berkley DB to sqlite. However old libguestfs actually >> accessed the BDB directly and could not read the RPM databases of new >> guests. So we switched to using librpm (instead of direct access), >> but this meant for a time we couldn't access the RPM DBs of *old* >> guests. However that was eventually fixed in RPM. >> >> https://github.com/libguestfs/libguestfs/commit/c9ee831affed55abe0f928134... >> >> Rich. >> >>> The file "/usr/lib/rpm/rpmrc" absolutely exists in the guest (I booted it up separately, and checked it). >>> >>> It seems that "internal_list_rpm_applications" [daemon/rpm.ml] calls chroot, and uses a child project -- can that be related to the issue? >>> >>> Anyway, I think I'll post v2, just saying that I could not actually test it. >>> >>> Thanks, >>> Laszlo >> >> -- >> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones >> Read my programming and virtualization blog: http://rwmj.wordpress.com >> Fedora Windows cross-compiler. Compile Windows programs, test, and >> build Windows installers. Over 100 libraries supported. >> http://fedoraproject.org/wiki/MinGW >