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

[Richard W.M. Jones]

On Wed, Dec 15, 2021 at 04:40:22PM +0100, Laszlo Ersek wrote:
> 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).

The bottom line is still that it's librpm's problem now to handle any
guest rpmdb, no matter how ancient (well, at least RHEL >= 5).  If you
have the latest rpm installed and it still doesn't work then it could
be a bug in librpm, although I'm pretty sure I tested this case.

Easy test is something like:

$ virt-builder rhel-5.10
$ virt-inspector -a rhel-5.10.img

(I'll send you privately some links to make those commands work)

Rich.

> 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/c9ee831affed55abe0f928134cbbd2ed83b2f510
> >>
> >> 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
> > 

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/