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

Laszlo Ersek lersek at redhat.com
Wed Dec 15 15:14:42 UTC 2021


On 12/15/21 11:57, Richard W.M. Jones wrote:
> On Wed, Dec 15, 2021 at 11:17:51AM +0100, Laszlo Ersek wrote:
>> I *really* dislike the one aspect of the current multi-line messages
>> that they are nailed to column #0. It disrupts the code flow for me. For
>> example, consider the following snippet from this very file
>> [convert/convert_linux.ml]:
>>
>>                 g#cp grub_config uefi_grub_conf;
>>                 let fix_script = sprintf
>> "#!/bin/bash
>> efibootmgr -c -L \"CentOS 6\"
>> rm -rf %s" uefi_fallback_path in
>>                 Firstboot.add_firstboot_script
>>                   g inspect.i_root "fix uefi boot" fix_script)
>>
>> I find it less than ideal.
>>
>> I'd really like to indent such strings logically. And that's exactly
>> what the backslash is for (I had checked the ocaml documentation): after
>> an escaped newline, leading spaces and tabs are dropped. I think that's
>> a fantastic feature of OCaml; I used it intentionally.
> 
> Right, this is indeed a reason to use the \, as it drops the following
> whitespace.
> 
>>> You can just match to arbitrary depth in single match statements, so
>>> the whole match would become something like:
>>>
>>>   let map = map @
>>>     match cdroms with
>>>     | { Some Source_IDE, Some slot, `RHEL_family v } :: _ when v <= 5 ->
>>>            [("hd" ^ drive_name slot, "cdrom")]
>>>     | _ -> [] in
>>
>> Does this make the code easier to read to you? (Honest question.) To me,
>> this does not separate the steps "take first" and "investigate first",
>> and so it's harder to read. But if that's only because I don't have
>> enough OCaml experience yet, I'm happy to change it. (Because, in
>> comparison, you might find the two "match" expressions to be the
>> distraction.)
> 
> For me it's less code => better, within reason. The above (after
> fixing the bugs - see later emails) is more natural.

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

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)>

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




More information about the Libguestfs mailing list