Richard W.M. Jones
2021-Dec-15 15:51 UTC
[Libguestfs] [PATCH] convert_linux: translate the first CD-ROM's references in boot conf files
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/
Laszlo Ersek
2021-Dec-16 08:35 UTC
[Libguestfs] [PATCH] convert_linux: translate the first CD-ROM's references in boot conf files
On 12/15/21 16:51, Richard W.M. Jones wrote:> 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.The latest "rpm" package in Fedora 34, rpm-4.16.1.3-1.fc34: https://koji.fedoraproject.org/koji/buildinfo?buildID=1726304 built on 22 Mar 2021, does not (cannot) have the fix. The upstream rpm fix is: https://github.com/rpm-software-management/rpm/commit/ea2754b4f14e0a195f4633adfcaa59d0167ee676 which is between tags "rpm-4.17.0-alpha" and "rpm-4.17.0-beta1", and has commit date 2021-06-11. The fix has been backported to RHEL-9 (1965147): https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1824746 but not to Fedora 34. Fedora 34 is supposed to be maintained until 2022-05-17, according to Wikipedia, so this is definitely a Fedora bug. I guess I should update my workstation to Fedora 35 regardless; that should be faster. (Fedora 35 has rpm-4.17.0-1.fc35, so it should have the fix.) Thanks Laszlo