Login

***frednork*** · (This post was last modified: 14-Jul-2023, 11:44 PM by frednork.)

Just installed on another nuc successfully just days ago. Now when I install it shows

I tried on another nuc and then with another drive. Same issue. redownloaded, same issue. updated same issue

This is with Ubuntu 22.04.2 LTS. nucs are nuc7i7 and nuc10i3.

***agent_kith*** · 15-Jul-2023, 08:36 AM

(14-Jul-2023, 11:38 PM)frednork Wrote: Just installed on another nuc successfully just days ago. Now when I install it shows

I tried on another nuc and then with another drive. Same issue. redownloaded, same issue. updated same issue

This is with Ubuntu 22.04.2 LTS. nucs are nuc7i7 and nuc10i3.

Can you run this command where the installer file is:

Code:
sha1sum snakeoil-installer-x86_64-1.2.6.sh

And confirm you get the following output:

Code:
c0d0ab9b8d64e3f6a0d495f974679b511b87ca0c  snakeoil-installer-x86_64-1.2.6.sh

And also this:

Code:
ls -l snakeoil-installer-x86_64-1.2.6.sh

You should see this something like so:

Code:
119907996 Jul 15 07:07 snakeoil-installer-x86_64-1.2.6.sh

If:

the file size (119907996) don't match, your download is incomplete and you'll need to re-download the file.
the file size is correct, but the checksum (c0d0ab9b8d64e3f6a0d495f974679b511b87ca0c) is different, then the download is incomplete.

In the two cases above you have to bypass any caching software (proxy) you or your ISP have.

Now if both numbers are correct, and you run the installer and still get the same error as your screenshot, then it's likely to be bad RAM (or other problem hardware). If it's bad ram or other hardware your system will usually be unstable under load (either freezing or rebooting). To be honest I don't think this will be the case as I havn't experience bad hardware for a long time now (even on second hand gear). A good test is to re-run the installer and compare the string of numbers in your screenshot, if they are always different when you run the installer, then it's a hardware issue.

***frednork*** · 16-Jul-2023, 11:10 AM

Thanks for that, I have been following your instructions and all checksums are bad. Interestingly the file I downloaded a few days ago which allowed me to setup snakeoil on another nuc is also bad. So after trying different files, different nucs, different drives, redownloading etc I decided to try another laptop entirely from scratch. All has worked as it should so obviously no issue on snakeoils end so thats good.

Obviously outside your remit but any suggestions on what is going on with the laptop that is no longer able to set up snakeoil would be appreciated.

***agent_kith*** · 16-Jul-2023, 11:23 AM

(16-Jul-2023, 11:10 AM)frednork Wrote: Obviously outside your remit but any suggestions on what is going on with the laptop that is no longer able to set up snakeoil would be appreciated.

Hard to say without more information, as anything is possible.

Things from bad ram, failing ssd/hdd, old flash drives (if you use that to copy files), laptop infected with some unknown viruses, transferring files in ASCII mode and not BINARY mode, modifying the installer file, and probably hundreds (if not thousands) of other possibilities.

Just a single bit change in the installer file will cause that error. And the installer will not continue (this is a good thing) because the installation file is no longer what it's supposed to be.

***frednork*** · 16-Jul-2023, 11:29 AM

interesting development, just found that the files on the "bad" pc are fine and return the correct checksum so this points to the transfer maybe? will try different transfer method

***frednork*** · (This post was last modified: 17-Jul-2023, 07:40 AM by frednork.)

Just for anyone with a similar issue, it ended up being that winscp was set to default transfer method which previously worked fine for some reason but then no longer was fine as when I set it to binary and the transfer worked. problem solved!

Many thanks to AK for his help in tracking this down.

***agent_kith*** · 17-Jul-2023, 07:59 AM

(17-Jul-2023, 07:39 AM)frednork Wrote: Just for anyone with a similar issue, it ended up being that winscp was set to default transfer method which previously worked fine for some reason but then no longer was fine as when I set it to binary and the transfer worked. problem solved!

Many thanks to AK for his help in tracking this down.

Great. So it's ASCII vs binary then. Will add a note in the wiki on this. It's a good issue to find. Thanks for your patience.