[Libguestfs] [PATCH v2v] Add ALT support

[Pino Toscano]

On Monday, 24 August 2020 19:48:07 CEST Richard W.M. Jones wrote:
> From: Mikhail Gordeev <obirvalger at altlinux.org>
> 

It would be nicer to have few more details in the commit message
and/or comments in the code, as there are things that definitely
deserve explanations.

Also, IMHO, it would be nice to have it split in different parts:
1) a simple patch that adds the ALT_family, in case it is needed (see
   below why IMHO it might not be)
2) a simple patch adding the distro in the register_convert_module
   matching function, and mentioning it in the documentation
3) the patch for the initrd work needed
4) the patch (if needed, see below) for the vmware tools libraries

Also, in patch (2) could go also the addition of ALT Linux to
docs/virt-v2v-support.pod.

> @@ -372,6 +373,9 @@ let convert (g : G.guestfs) inspect source_disks output rcaps _ =
>              );
>          ) libraries
>        )
> +      else if family = `ALT_family then (
> +        remove := libraries
> +      )

The "if" of this else is:

      (* We only support removal of libraries on systems which use yum. *)
      if inspect.i_package_management = "yum" then (

This is done to resolve the packages that provide the installed VMware
libraries. The library packages are found earlier:

        if String.is_prefix name "vmware-tools-libraries-" then
          List.push_front name libraries

So any package that starts with "vmware-tools-libraries-". From what I
remember, this pattern was used by very old packages provided by VMware
in their repository, and most probably even newer packages are not
using them anymore (in favour of vmware-tools).

The question is: do VMware tools package exist on ALT Linux? If so,
what are their package names? I don't think that VMware provide
packages for ALT, leaving only the open-vm-tools ones as possible.
Hence, unless strictly needed, I'd rather not include the above part.

> @@ -657,6 +661,50 @@ let convert (g : G.guestfs) inspect source_disks output rcaps _ =
>  
>          run_update_initramfs_command ()
>        )
> +      else if family = `ALT_family then (
> +        (* ALT utilities to work with initrd does not support adding modules
> +         * to an existing initrd
> +         *)

So how are users supposed to include modules they want? Recreating the
initrd manually every time?

What about https://en.altlinux.org/Make-initrd ?

> +        let kver = kernel.ki_version in
> +        let kmodpath = kernel.ki_modpath in
> +
> +        (* find module files *)
> +        let files = g#find kmodpath |> Array.to_list in
> +        let test f =
> +          let r m = sprintf ".*/%s\\.ko$" m |> Str.regexp in
> +          let rmodules = List.map r modules in
> +          let fold_f acc mr = acc || Str.string_match mr f 0 in
> +          List.fold_left fold_f false rmodules in
> +        let files = List.filter test files in

kernel.ki_modules contains already a list of modules for that kernel,
so why are you searching for them again?

> +        (* create new initrd with contents of old initrd *)
> +        let tmpdir = g#mkdtemp "/tmp/new_initrd-XXXXXX" in
> +        let old_initrd = initrd ^ ".pre-v2v" in
> +        let cmd = sprintf "gzip -cd %s | cpio -imd --quiet -D %s"
> +          old_initrd tmpdir in
> +        ignore (g#sh cmd);
> +
> +        (* copy module files to new initrd *)
> +        List.iter (fun file ->
> +          let dir_name = Filename.dirname file in
> +          let dir_name = sprintf "%s%s%s" tmpdir kmodpath dir_name in
> +          g#mkdir_p dir_name;
> +          g#cp (sprintf "%s/%s" kmodpath file) dir_name
> +        ) files;

So we are creating an initrd with all the modules of the kernel?
Is there really no way to just add the required modules for booting?

Thanks,
-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200825/f8c465ab/attachment.sig>