SugarCRM - Business & Social CRM software

V 14.2: 333MB VM

Replies (8)

Hmm, ok thanks for reporting.

Reply 1 2017-05-09

Thanks so much for reporting this. I'll have a look ASAP and see what's going on.

From your screenshot, it looks like an oversight on our behalf. We have updated the hashes we use to be more complex but it looks like we missed something with the OVF/OVA build (or perhaps it doesn't support the new format?). I tested the Core build, which in theory should have shown something like this. However obviously that's not the case...

FWIW I've lodged it as a bug on our tracker.

I'll look into it closer within the coming days. In the meantime, perhaps just try the VMDK or the ISO?

I was attached screenshot...

Reply 2 2017-05-09

I was attached screenshot...

i'll try again.

Hi. Any problems?

Reply 3 2017-05-08

Hi there. Did you mean to post a question or some feedback regarding v14.2 SugarCRM appliance? I'd love to hear!

FWIW I just published the blog post announcing the new SugarCRM build (among others).

Can you please tell me more about your software?

Reply 4 2017-05-10

This is a bit weird. FWIW we use VMware's OVFTool to create our OVA files so I'm not sure why this is broken. Although we do tweak them slightly, so I thought that may be the issue? However, I have just tested this in VMware's Workstation Player (12.5.5 build-5234757) and am getting mixed results. Also I'm running on Debian Jessie so perhaps that's a factor?

If I just double click the OVA, I get an error message:

Unable to open /home/user/v14.2/turnkey-drupal8-14.2-jessie-amd64.ova as a Virtual Machine:

VMX file is corrupt.

But that's a pretty weird error message considering that the OVA doesn't even have a VMX file in it (nor should it).

If I open VMware Player and then import the OVA (via File >> Open a virtual machine) then it just works?! No errors or messages of any sort?! It then boots and runs fine too!? FWIW the OVA also imports into VirtualBox without any errors or messages?!

I wonder if there is some VMware bug of some sort? Or perhaps we need to tweak things a bit to support older/newer versions of VMware software? So please share what version. Perhaps too you can check you VMware logs to see if there is further info? Also perhaps it's worth trying an alternate import method (as I did)?

I'm guessing that you are running an old version?

Reply 5 2017-05-23

As per my response to another post and my comment on the issue tracker, this appears to be a compatability issue between VMware's OVFTool (what we use to create the OVAs) and older VMware products.

I'm testing to see if we can include backwards compatibility so it'll work everywhere, but users of newer systems still get the security advantage of using SHA256 checksums.

Hi again

Reply 6 2017-05-26

I have built a new v14.2 OVA which I need to test (I don't have ESX/ESXi). COuld you please get in touch ASAP so I can give you a link to download the test build. My email is jeremy AT turnkeylinux.org

Same to anyone else reading this (who has ESX/ESXi/vSphere ~ v5.5), please get in touch ASAP.

Ah ha, thanks for posting back.

Reply 7 2021-08-26

Ah ha, thanks for posting back - although it'd be interesting to know which versions of VMware and TurnKey this is for?

FWIW we build our OVAs using VMware's OVFTool. We try to make our OVAs compatible with as many different releases as possible, but it appears that VMware changes the requirements for each version fairly commonly...

SOLVED

Reply 8 2021-08-25

need to change checksums in .mf file to sha1