Windows Quick Start Extraction issues

[LegendaryB]

Hello,

as mentioned in #1241 the windows quick start is failing. The installation hangs at the 7zip extraction. Do you guys have a fix for this?

My system is windows 10 64 bit

Kind Regards Daniel

[kwis2]

I have no solution, but there is way how to go through the problem. On my win 7 64 bit installation hangs on 7zip. I open another cmd windows and manually run commands which 7zip is unable to run. in my system it is four times hangs, in your system there should be different paths .

7z.exe x "C:\Users\nnn\AppData\Local\Temp\chocolatey\mingw-get\mingw-get-0.6.2-mingw32-beta-20131004-1-bin.tar.xz" -o"c:\inst"
7z.exe x "C:\inst\mingw-get-0.6.2-mingw32-beta-20131004-1-bin.tar" -o"C:\tools\MinGW"

7z.exe x "C:\Users\nnn\AppData\Local\Temp\chocolatey\mingw-get\mingw-get-0.6.2-mingw32-beta-20131004-1-lic.tar.xz" -o"c:\inst"
7z.exe x "C:\inst\mingw-get-0.6.2-mingw32-beta-20131004-1-lic.tar" -o"C:\tools\MinGW"

7z.exe x "C:\Users\nnn\AppData\Local\Temp\chocolatey\mingw-get\mingw-get-setup-0.6.2-mingw32-beta-20131004-1-dll.tar.xz" -o"c:\inst"
7z.exe x "C:\inst\mingw-get-setup-0.6.2-mingw32-beta-20131004-1-dll.tar" -o"C:\tools\MinGW"

7z.exe x "C:\Users\nnn\AppData\Local\Temp\chocolatey\mingw-get\mingw-get-setup-0.6.2-mingw32-beta-20131004-1-xml.tar.xz" -o"c:\inst"
7z.exe x "C:\inst\mingw-get-setup-0.6.2-mingw32-beta-20131004-1-xml.tar" -o"C:\tools\MinGW"

Very important it is to run every commands while 7zip hangs, and then kill 7zip window. Bad news is that even after such procedure there are PC where sming fail to install.

Worst info is that I don't know working solution for windows (7) users except install linux - choco fail, direct install fail, docker fail, virtual box with linux - success except it is not able to program ESP - USB driver hangs. And there is no hope for solution

[LegendaryB]

This has worked somehow. But it failed while installing sming because its using a wrong filepath. also the filepath while extracting was false.

I think the scripts should maybe be updated?

[kwis2]

I was wondering why is may old win7 work, but new machines failed. Difference is that on old system I have started from sming 2.1.0, while new from sming 3.0 and above. I think I have procedure to install sming. It is compilation of windows and linux install methods. I have tested with success on VM win7 32bit. First install environment - use old choco method from sming 2.1.5 it will install very old sming 2.1.0 but properly set system. I don't know if it matter but I have installed newest jre8 before. there is no information in quickstart, but you have to reboot system before make works. After success you have to install new UDK UDK link. I removed old UDK from c:\Espressif and installed 2.2.2 version. Additionally you have to install git - I installed from git of course reboot and then you are ready to install sming... My working way is to use git - first delete sming forder from c:/tools. with cmd as admin goto c:/tools and then type git clone https://github.com/SmingHub/Sming.git sming here you could decide which version would you like to install - if you would like stable version use git checkout origin/master now you are ready to make sming, but there is problem with spiffy compile. By unknown reason mingw stop with error. The way I found it is to copy files

libgcc_s_dw2-1.dll, libgmp-10.dll, libiconv-2.dll, libisl-15.dll, libmingwex-0.dll, libmpc-3.dll, libmpfr-4.dll

from c:\tools\mingw64\bin to c:\tools\sming\Sming\spiffy

then goto c:/tools/sming/Sming and now you are ready to make ;))

I use netbeans. With first run after install it fail to make project. Solution is to run make from command line and then netbeans compile without problem. Warnings. sming would like to install itself to c:\tools\Sming\Sming and then fail to install. You have to check and rename it to c:\tools\sming\Sming

[kwis2]

Finally procedure to make examples. You have to install esptool2 with cmd as admin goto c:\tools nad git clone https://github.com/raburton/esptool2 then goto c:\tools\esptool2 folder and make. Now you should add esptool2 path, but I have copied esptool2.exe to c:\tools\mingw64\bin folder. then it will ask for python - in cmd type choco install python and after reboot on my machine I was able to compile Basic_Blink. It looks OK, but I have no ESP module to test if all work.

[slaff]

Guys, can you open an issue here: https://github.com/slaff/chocolatey-packages and paste all the logs that you have and your guesses what can be the issue.

[kwis2]

@slaff I am not sure but there are issues disabled in https://github.com/slaff/chocolatey-packages I am not able to create one

[slaff]

@kwis2 Thanks for noticing this. Now it should be possible to add issues: https://github.com/slaff/chocolatey-packages/issues

[Matzz]

Maybe it's not closely related but I had similar issues because of Windows Subsystem for Linux which was "hiding" cygwin bash.

[frankdownunder]

For what it is worth, I use the newest version of WSL, Windows Subsystem for Linux, which is now installed from the app store and is called just Ubuntu. (Note that it supports command line stuff only). I use a Windows editor (actually Visual Studio), and my own scripts to call make and so forth. Its better than cygwin IMO.

[EveningStarNM]

It will be helpful (and merciful) to Windows users to note on the ReadMe that they shouldn't waste their time trying to install Sming. As far as I can tell, it can't be installed on Windows 10 1607 or later, despite the fact that Windows is prominently (and incorrectly) listed as a platform on which it can be installed. I just wasted an hour, and now I have to clean up all of the useless files that were downloaded and installed in the process of failing at the very end. I am far less than happy when my time is wasted. I won't be trying Sming again, and I must recommend against it to my colleagues.

[slaff]

@EveningStarNM I tried recently to install Sming on a fresh new Windows 10 Virtual Machine and it seem to work after installing for quite some time. Can you tell me what are the issues that you have experienced?

[lawrence-jeff]

@slaff I too am having issues using the Sming install process on Win10 64 bit - 7za windows open and just hangs. Digging into the chocolateyInstall script for mingw-get the extract line is Start-Process "7za" -ArgumentList "x "$filePath" -so | 7za x -ttar -si -y -o"$installDir"" -Wait The pipe symbol in there is being passed to 7za I suspect that was intended to be passed to a command shell so you can take the output of one 7za command and pass to another 7za instance. so I changed the command to Start-Process "cmd" -ArgumentList "/c 7za x "$filePath" -so | 7za x -ttar -si -y -o"$installDir"" -Wait

This seems to fix it as now its a command shell getting both 7za commands and the pipe now is being passed to cmd not 7za

[slaff]

@lawrence-jeff Wow! Thanks a lot for the research. Please, make a PR with the suggested changes to this repository https://github.com/slaff/chocolatey-packages and I will take care to review and merge the changes.

[lawrence-jeff]

I noticed this is still an issue when reinstalling today on a clean Win10 64 bit box. I saw the same thing where 7za was hanging, looking at the command line passed to this I see the Pipe is still in there which is tripping it up (see info from last year). I'm not sure how this isn't failing for everyone that uses the quickstart instructions for windows. I can't seem to find the line that runs 7za in any of the repository files or would submit a PR as requested. Any pointers?

After digging, it appears the process is grabbing some really old code. I'm not sure how choco gets its source, but the bug I am finding appears to have been fixed in this commit in 2015.. yet a clean install of Windows and chocolatey following the quickstart pulls this install..

https://github.com/rjocoleman/chocolatey-mingw-get/commit/05b0deb7aadb8e21f70caf84ae752ce203ab69a8#diff-c8f6abc2ccedfe23bdef7041bb85de5f8e2ed640a05c59d7fad3411951f36a54

[mikee47]

Try the manual install for now - I'll look at a fix for the auto install, thanks for the info.

[mikee47]

@lawrence-jeff The choco install should now be fixed. You'll need to do this post-install:

• Open a new command window so environment is updated
• Run these commands:

set PYTHON=python
cd c:\tools\Sming
git checkout develop

Changes:

• ESP8266 UDK is outdated, pulls in gnu20 version of esp8266 ESP quick toolchain (GCC 10.2)
• Pulls in master Sming branch - not currently compatible with GCC 10.2 (requires 4.1.2) hence switch to develop branch.
• Installs CMake and GIT

[lawrence-jeff]

@mikee47

Ok - better but still not quite working without some changes One thing I notice is the SMING_HOME variable created doesn't seem correct - it is C:\tools\Sming where on the manual install it is set to c:\tools\Sming\Sming (which seems the correct value as it complains until this is fixed) Also didn't follow Set Python=python, should the environment variables be Set PYTHON=C:\Python39\python.exe Setx PYTHON C:\Python39\python.exe Since 3.9 is installed by choco and we know it will be in that path?

Set isn't persistent and Setx doesn't apply without a new shell so running them both covers both scenarios Also for me git checkout develop didn't work, it results in this fatal: not a git repository (or any of the parent directories): .git So i deleted the existing folder installed by choco and then ran git clone https://github.com/SmingHub/Sming --branch develop

I can now compile the basic blink sample.. If you want to update the instructions to match I am happy to spin up another clean machine and go through it step by step. I wasn't sure if the line ending and Eclipse install pieces should still be in the docs after these changes.

[mikee47]

@lawrence-jeff Thanks for checking this out. I've updated the installation instructions which hopefully will clarify some points. See here https://smingdev.readthedocs.io/en/update-install-docs/arch/esp8266/getting-started/windows.html.

PYTHON

I'm not sure on the best way to handle python installs... it seems what works on one system breaks on another! I've not specified any particular python version, but perhaps this should be fixed so we can set the path explicitly as you suggest.

Set isn't persistent and Setx doesn't apply without a new shell so running them both covers both scenarios

After installation please close the administrative shell and open a new, regular one. The installer sets SMING_HOME and ESP_HOME as system-wide variables so they do not need to be set every time a command prompt is opened, and will be seen by eclipse without any further configuration.

Also for me git checkout develop didn't work, it results in this fatal: not a git repository (or any of the parent directories): .git So i deleted the existing folder installed by choco and then ran git clone https://github.com/SmingHub/Sming --branch develop

The script is correct, possibly c:\tools\sming existed prior to install?

I can now compile the basic blink sample..

Hooray!

If you want to update the instructions to match I am happy to spin up another clean machine and go through it step by step. I wasn't sure if the line ending and Eclipse install pieces should still be in the docs after these changes.

I've removed these steps from the instructions. Further suggestions most welcome, thanks again.

[lawrence-jeff]

@mikee47 Hey Mike -I will spin up a new clean VM and go through the updated instructions to help validate. I notice you don't have pulling in the dev branch in the updated instructions but did in this thread - is that no longer needed? (or built into the choco)

[mikee47]

@lawrence-jeff For now you'll need to pull in the develop branch manually, but once 4.2.0 is released this step won't be required.

[lawrence-jeff]

Ok - spun up a clean Win10 VM (in Azure MSDN subscription - so a default clean install) Ran through the instructions line by line Items I noticed

• "Now, open an administrative command prompt and run:" under the choco sming part - You don't need this line, if you are following the instructions you still have an administrative cmdline open from the earlier steps

The SMING home variable as I mentioned above still doesn't seem correct. Following the instructions to compile blink the first line doesn't work because the cd command points at the wrong path (or the variable is incorrect). If I add back in the missing SMING directory it works again. See screenshot

[mikee47]

But you're still in the administrator command prompt. If you open a new (non-admin) command prompt, SMING_HOME should be correct. Can you check?

[lawrence-jeff]

That is a new command window as the instructions indicate (why there is no command history from the installs above). I'm not sure why it shows as 'administrator' in the title bar, I'm not explicitly running it as admin, just opening cmd from the start menu. Just to be sure I rebooted the machine, and here are the variables in a fresh window. It still shows as 'administrator' which I'm not sure why - in my experience you have to explicitly select run as admin for that to occur - but this is a MS Azure Win10 build template for development so perhaps they have it configured differently. I don't think administrative context would change the value of a system env variable but if you really want I can create a non admin account on the box and see if it differs.

[lawrence-jeff]

Perhaps more relevant from the choco logs

2021-01-01 15:17:43,920 1468 [DEBUG] - Running Install-ChocolateyEnvironmentVariable -variableName 'SMING_HOME' -variableValue 'C:\tools\sming' 
2021-01-01 15:17:43,920 1468 [DEBUG] - Running Set-EnvironmentVariable -Name 'SMING_HOME' -Value 'C:\tools\sming' -Scope 'User' 

[mikee47]

That's an old version! Can you dump the entire choco log? Might shed some light on what's happening...

[lawrence-jeff]

chocolatey.log

[mikee47]

OK, I see where I've gone wrong. I assumed that the latest package versions would be used, but they need to be explicit.

I'll do some updates and drop you a note when it's ready.

(My testing didn't use fresh VM so guess the packages were cached somewhere. Sorry.)

[lawrence-jeff]

Np- that is why I volunteered to help test, always good to have a second pair of eyes on things

[mikee47]

I've been chewing on this one a little. My current thinking is to get rid of sming.core entirely, just add that as a manual step. That way, the installation only deals with the tools and not Sming itself, which is more consistent with how the linux install works.

[slaff]

My current thinking is to get rid of sming.core entirely, just add that as a manual step. That way, the installation only deals with the tools and not Sming itself,

@mikee47 I like the idea but let's leave this change for 4.3. 4.2.x will be LTS. Ping me when this PR is ready so I can merge it and start the release process for the long awaited 4.2.0 :)