Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I modified a .bin file for the software ELAN so the path to one of my libraries is correct (after installation, ELAN can't find the library because the path is not right). So I used Emacs to correct this.

But when I use the commands to install the .bin file:

sudo chmod +x ELAN_440_linux_novm_install.bin

I get the error message:

Preparing to install...
Extracting the installation resources from the installer archive...
The size of the extracted files to be installed are corrupted.  Please try to download the installer again and make sure that you download using 'binary' mode.  
Please do not attempt to install this currently downloaded copy.

This is probably because I added a few characters to the problematic string.

Is there a way to force the installation, as I know that the file wasn't corrupted before I edited it?

share|improve this question
Modification of the install file corrupted its checksum. Wouldn't you consider to fix the PATH issue differently, e.g. using symlinks? – Izzy Jul 25 '12 at 8:42
What are symlinks? I have to replace the string > nptl="strings /lib/ | grep -i nptl" by > nptl="strings /lib/i386-linux-gnu/ | grep -i nptl" I guess there is no way moving is a good idea... – stragu Jul 25 '12 at 9:08
see my answer below. Just thinking: Could it be your elan stuff is 32bit, while your Ubuntu installation is 64bit? If so, and you are running into additional problems with libraries not being found, you should rather consider installing the compatibility layer before doing the symlink stuff below. Make sure you've got ia32-libs installed in the first place then - and only do the symlink if the file is not already there. Point is: 32bit apps cannot use 64bit libs directly, and vice versa. – Izzy Jul 25 '12 at 9:43
The software is made for 32 bits, and I am using 32 bits, so it's all good. I'll try the answer, cheers! – stragu Jul 26 '12 at 5:21
OK, then it's fine. Just wanted to make sure we avoid additional trouble ;) So go on with my answer. I did that a lot of times successfully, so I'm pretty sure it will work out for you (using the unaltered installation package, of course ;) – Izzy Jul 26 '12 at 6:08
up vote 2 down vote accepted

Manipulating installation files is a bad idea in most cases like this. As you already noticed, this broke the checksum (maintained to ensure noone tampered with it and possibly introduced malicious code). A much better idea is to solve such issues outside, either by adjusting path variables (which would not work in this case), or by the use of symbolic links.

In your case, the solution is as easy as

ln -s /lib/i386-linux-gnu/ /lib/

So when looking for /lib/, the binary finds the symlink and "gets redirected" to /lib/i386-linux-gnu/ (to put it into easy words -- how it works exactly, you can read in the linked Wikipedia page; but for your understanding it suffices to think of it as a special kind of "bookmark" -- so even if the file itself gets replaced, the symlink stays valid, pointing to the updated file then).

share|improve this answer
So, after running this command, does the symlink stay? Or do I have to create it every time I want to use the program? – stragu Jul 26 '12 at 7:28
Great, this worked, I don't get the error message any more. Cheers! – stragu Jul 26 '12 at 7:42
Glad that it worked out -- but to be honest, I didn't expect anything else ;) The symlink stays until you remove it again. Think of it as a "virtual file" or, if you are a programmer, a "pointer". – Izzy Jul 26 '12 at 9:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.