stefantalpalaru
commented
1 month ago Going and extracting the tarballs from the softwareupdate.vmware.com site isn't too much of a hassle
Which tarball and where exactly is the Windows ISO?
Closed shadowgamer67890 closed 1 month ago
stefantalpalaru
commented
1 month ago Going and extracting the tarballs from the softwareupdate.vmware.com site isn't too much of a hassle
Which tarball and where exactly is the Windows ISO?
shadowgamer67890
commented
1 month ago They can be found at https://softwareupdate.vmware.com/cds/vmw-desktop/ws/17.5.2/23775571/linux/packages/
Each one is a .component file with a descriptor.xml inside of a tarball, and the .iso lives inside of the .component. I have no idea how the .component file is compressed but I'm able to get the .iso out of it with 7-Zip so that's how I've been getting it. Hitting the info button while in 7-Zip claims gzip compression, but I can't actually get it to unzip from the command line that way, so I'm not sure what's going on there.
Quick edit: Worth noting I found this link from the UI log that lives at /tmp/vmware-(username)/vmware-ui-(pid).log which also complains the reason for install failure is "Your copy of the VMware Installer is too old." The vmware-installer at /opt/vmware/lib/vmware-installer/3.1.0 and the metadata.xml from the same link as the tarballs having <version>3.5</version> on the second line would suggest this to be correct I suppose.
shadowgamer67890
commented
1 month ago So first I've realized my earlier comment on the version in the metadata.xml is totally unrelated to the vmware-installer version so ignore that part, but I've figured out enough about the component files to get the iso out without 7-Zip. They seem to consist of:
-Some unknown header -The exact data of the descriptor.xml also found in the tarball -The ISO gzipped
all back to back. This ugly script got the ISO out by way of grepping the offset of <component/> which every descriptor.xml has, adding 12 which is the byte length of said component end tag, lopping off the header and xml, and finally gunzipping the iso.
tar -xf vmware-tools-windows-12.4.0-23259341.x86_64.component.tar
TAGOFF=$(grep -boa "</component>" vmware-tools-windows-12.4.0-23259341.x86_64.component | cut -d ":" -f 1)
dd if=vmware-tools-windows-12.4.0-23259341.x86_64.component of=windows.iso.gz bs=$(($TAGOFF+12)) skip=1
gzip -d windows.iso.gz
Perhaps this can be incorporated into the ebuild in some way?
stefantalpalaru
commented
1 month ago Done. Thank you for doing all the work!
There is still something wrong with how we create our sqlite database, so these tools are not picked up as installed by the GUI.
This isn't about the "Install VMware Tools..." button not working, I know you need to manually pick the iso from /opt/vmware/lib/vmware/isoimages. Thing is that directory has been barren for the last update or two aside from the manifest txt file, and enabling every single guest tool USE flag interestingly only results in macOS tools appearing. Going and extracting the tarballs from the softwareupdate.vmware.com site isn't too much of a hassle, but the Windows ones were definitely there when I first installed the package and now they don't seem to be...
emerge info, build log, and pqv just because info.txt build.log pqv.txt