OVA file order and checksum issues

[forkineye]

Describe the bug
There are two issues I've found which prevent OVA files generated from being imported into VMware Workstation or processed with ovftool. I have reproduced this with RedHat 8.9 and RedHat's cloud service. If this needs to split into two issues or filed elsewhere, please let me know. I'm a developer without a RedHat subscription, hence filing the issue here.

• The first involves the order of the ova archive. VMware Workstation and ovftool both insist that the ovf file be the first file within the archive.
• The second has to do with how the vmdk is being generated, which causes checksum validation to fail.

Environment

• RedHat 8.9 (generated rhel8 image locally)

  • osbuild-composer-88-1.el8

• https://console.redhat.com/ (generated rhel9 image in cloud)

  • compose json: request-b645cb3e-a21d-478f-ad50-d621a7d64921.json

• Windows Pro 22H2

  • VMware Workstation Pro 17.0.2 build-21581411
  • ovftool 4.4.0

To Reproduce

• Using the attached json, generate a rhel9 image at https://console.redhat.com
• Extract the OVA with ovftool: ovftool <image>.ova <image>
  or
• Open <image>.ova in VMware Workstation

Expected behavior
For it to work :)

Additional context
Upon importing into VMware Workstation or processing with ovtool, both complain that with the following:

Performing the following, specifying the ovf file first, results in composer.ova that rectifies the first issue.

$ mkdir composer; cd composer
$ tar xvf ../composer-api-715edf78-fc2a-4daa-b4f8-9ae2201b02d3-image.ova
image.vmdk
image.ovf
image.mf
$ tar cvf ../composer.ova image.ovf image.vmdk image.mf
image.ovf
image.vmdk
image.mf

The 2nd issue is that sha256sum for the vmdk does not pass with VMware Workstation or ovftool, even though the checksums match when performed manually:

$ cat image.mf
SHA256(image.ovf)= 6da8f04757080733d31aba0ef670385c505e75963c0e72371b63603ec69dfb1b
SHA256(image.vmdk)= 3f1c81e5fc5285501c3d90d72115b563ca0beaa35443799536d942f7df570156
$ sha256sum.exe image.vmdk
3f1c81e5fc5285501c3d90d72115b563ca0beaa35443799536d942f7df570156 *image.vmdk

To rectify this issue, I can remove the manifest when re-building the OVA with tar, however this is not ideal. This issue seems to shed light as to what is going on, in particularly the usage of stream optimized output - home-assistant/operating-system#2121 (comment)

[bcl]

Thanks for the report, the file order issue is being worked on in osbuild/osbuild#1561