07-22-2015 10:42 AM
we are currently having a problem with installing the recently released SDSoC v2015.2 on Ubuntu 14.04 . The progress bar runs right through to 99% and everything seems to be fine, then we get an error message (from the xinstall log file):
2015-07-22 19:30:33,559 DEBUG: p.f:? - There was an error extracting files and user did not want to retry.
2015-07-22 19:30:33,560 DEBUG: p.g:? - Fatal error extracting archives, Error was encountered while extracting archive
/tmp/Xilinx_2015.2_SDSoC_0716_1/payload/sdintegrator_0009_2015.2_SDSoC_0716_1.xz<html><br/>The possible reasons can be: the disk is full, you've exceeded disk quota, or the destination directory is too long.<br/></html>
No, the disk is NOT full. There is no quota und the target file installation dir is just "/opt/xilinx/sdsoc/v2015.2" - not too long I would say (we also tried /opt/sdsoc20152 - even shorted and without dots - but: same result, same message).
Hitting the "Retry" button in the xinstall GUI does not help - xinstall stops again, with the same message.
We recently installed Vivado 2015.2 on the same machine, also using xinstall of course -- result: no problem in case of Vivado 2015.2.
We double-checked that our downloaded package is correct (via md5sum). However we are currently unaware of any method to check the consistency of the file the xinstall program is obviously having a problem with.
Anybody any ideas?
07-23-2015 09:10 AM
07-23-2015 09:53 AM
no we are not running as root. The way we always have installed, for example Vivado/ISE/... is:
- preparing the installation target directory: create + give installation user ownership (= rwx)
- launch xsetup, specify prepared installation directory in the GUI process and let the installer do its stuff
- later we move the installation to a file server for general access, in the process of this, we do "chown root.root" the whole thing.
And yes, the installation user does have rw to /tmp - standard Ubuntu 14.04.
Again, the thing is: Latest Installation of Vivado v2015.2 went fine exactly this way. Also, we installed SDSoC v2014.4 in the saem fashion without any problems. Why should SDSoc v2015.2 be any different?
Is there a way to check (e.g. md5sum) the file xinstall is complaining about?
Unfortunately we cannot unpack this file xinstall is complaining about ourselves - it seems to be 7z-compressed+password-protected archive - to see if a "standalone" unpacking is possible.
09-01-2015 12:05 AM
Yeah I know it's not polite to horn-in on an existing thread, and this one looks to have stalled, however I felt compelled to mention that I have just now run into the exact same issue trying to install Vivado 2015.2 on Fedora 22. Same basic premise - not running as root, getting extract errors in the xinstall log, 7za tests the archives OK but remarks about an incorrect password (I left the password blank when prompted for it), and for grins I tried re-installing 2014.4 which was previously successful, and it worked just fine under the exact same conditions. The md5sum for the entire archive is correct according to the downloads page of the Xilinx web site, and the tarball extracted without errors. It's the rdi extraction that's giving me problems. For the record, I downloaded the "Vivado 2015.2: Full Installer For Linux Single File Download Image Including SDK" last updated June 30, 2015.
It looks like something isn't quite right, at any rate. Does anyone have any suggestions on what I might try to get this resolved? Has anyone else successfully extracted the specific 2015.2 archive I referenced under Linux? Maybe the "All OS" archive might work better (oh, the pain, I have a slow DSL link)? Maybe the web install would provide different results? Should I create a separate post for my separate issue, or is it likely the same issue as the OP? Enquiring minds want to know :-)
09-01-2015 08:58 AM
Following up on this, I downloaded and ran the web install for 2015.2 and that completed without errors. It looks like there's something wrong with the password settings in the full Linux 2015.2 tarball, or perhaps the installer itself I suppose. That's just a guess, but it sure doesn't seem to be any type of disk space / permissions / OS incompatibility issue.
Any chance someone at Xilinx can check out that full Linux tarball and perhaps make it work? I like having the full monty on disk so re-installations take a few minutes instead of a couple of hours.
09-17-2015 01:21 PM