Intel NUC not connecting

Hi, I bout an intel NUC and now i’m trying to connect it with resin.
I having the same issue like this guy -> Intel NUC never comes up

The NUC is connected to a tested Ethernet cable.
Tested with resinV2.7.8/2.2.0 + rev1 in both dev/prod.

When the NUC boots after the installation it appears as offline/connecting on dashboard and never connects.

Hello,

have you followed all the steps as described in your dashboard when you tried to add a new nuc device to your application?

Yes, i did all the same.

I’ll have to ping the devices team.
Just to make sure: is it a new device that you are trying to connect for the first time? Is it something that used to work in the past? Is there any special setup? Are you behind a firewall?

Best,
ilias

Its a new device - bought it today, no special setup, no firewall.

Hey @Doise, just checked provisioning a resinOS 2.7.8 for the NUC, and worked right away.

If the device shows up in the dashboard, that means that the provisioning step is at least started, and the device was able to connect on the network. Does the device shut down after the provisioning (and change the status to “Post-provisioning”)? After that, removing the flash media and rebooting, is that it shows up as “offline”?

What hardware revision of NUC are you using?

If you are flashing the “dev” image, then there’s some local test you can do. If you start the device up after provisioning, if you can find the IP address of the device on the local network, you should be able to SSH in with the following command:

ssh -p 22222 root@<IP>

If getting in there, there are a number of things you can check for example systemctl status -u openvpn-resin for the VPN connection status or docker logs resin_supervisor for the supervisor logs.

I’m able to ssh into the NUC link to hardware specification ( Kingston 4GB DDR3, regular 2.5" HDD)

here’s the logs:

Docker logs:

init started: BusyBox v1.24.1 (2017-11-01 23:31:10 UTC)
starting pid 9, tty '/dev/stdout': '/usr/src/app/entry.sh'
starting pid 14, tty '/dev/stdout': '/usr/src/app/run.sh node /usr/src/app/dist/app.js'
starting pid 15, tty '/dev/stdout': '/usr/src/app/run.sh /usr/src/app/gosuper'
2018/01/11 16:42:36 main.go:65: Resin Go Supervisor starting
2018/01/11 16:42:36 main.go:45: Changing oom_score_adj for the supervisor container to -800
2018/01/11 16:42:36 main.go:50: Changing oom_score_adj for openvpn and connmand to -1000 if 0, every 5 minutes
2018/01/11 16:42:36 main.go:35: Starting HTTP server on /var/run/resin/gosuper.sock
[2018-01-11T16:42:40.928Z] Event: Supervisor start {}
[2018-01-11T16:42:40.945Z] Starting connectivity check..
[2018-01-11T16:42:40.982Z] New device detected. Bootstrapping..
[2018-01-11T16:42:41.210Z] Event: Loading preloaded apps failed {"error":{"message":"EISDIR: illegal operation on a directory, read","stack":"Error: EISDIR: illegal operation on a directory, read\n    at Error (native)"}}
[2018-01-11T16:42:41.216Z] Event: Device bootstrap {}
Thu, 11 Jan 2018 16:42:41 GMT body-parser deprecated bodyParser: use individual json/urlencoded middlewares at eval at <anonymous> (/usr/src/app/dist/app.js:283:59010), <anonymous>:14:44
Thu, 11 Jan 2018 16:42:41 GMT body-parser deprecated undefined extended: provide extended option at eval at wrapfunction (/usr/src/app/dist/app.js:1:112512), <anonymous>:4:11
[2018-01-11T16:42:41.457Z] Starting API server..
[2018-01-11T16:42:41.459Z] Starting Apps..
[2018-01-11T16:42:41.555Z] Finishing bootstrapping
[2018-01-11T16:42:41.588Z] Internet Connectivity: OK
[2018-01-11T16:42:41.716Z] Starting periodic check for IP addresses..
[2018-01-11T16:42:41.726Z] Updating supervisor version and api info
[2018-01-11T16:42:41.760Z] Event: Start application update poll {"interval":60000}
Thu, 11 Jan 2018 16:42:41 GMT body-parser deprecated bodyParser: use individual json/urlencoded middlewares at usr/src/app/dist/app.js:91:8489

VPN Connection:

   CGroup: /system.slice/openvpn-resin.service
           └─881 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/resi
n.pid --cd /etc/openvpn/ --config /run/openvpn/resin.conf

Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39mValidating certificate key usage[
[0m
Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39m++ Certificate has key usage  00a
0, expects 00a0[[0m
Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39mVERIFY KU OK[[0m
Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39mValidating certificate extended k
ey usage[[0m
Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39m++ Certificate has EKU (str) TLS 
Web Server Authentication, expects TLS Web Server Authentication[[0m
Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39mVERIFY EKU OK[[0m
Jan 11 16:44:43 95f62aa openvpn[881]: [[0;1;39mVERIFY OK: depth=0, C=US, ST=WA, 
L=Seattle, O=Resin.io, OU=VPN, CN=ResinVPN[[0m
Jan 11 16:44:44 95f62aa openvpn[881]: [[0;1;31mConnection reset, restarting [0][
[0m
Jan 11 16:44:44 95f62aa openvpn[881]: [[0;1;39mSIGUSR1[soft,connection-reset] re
ceived, process restarting[[0m
Jan 11 16:44:44 95f62aa openvpn[881]: [[0;1;39mRestart pause, 5 second(s)[[0m

~
(END)

Hi @Doise, I think you are hitting a known VPN issue that we are working on at the moment. Have a tentative fix ready that we are just verifying, and should be releasing soon when we tied down all the details. We are tracking the issue, and will keep you posted! Sorry about this!

Thank you for response.
Is there a workaround or something that I can do to fix it?
I really need to get this up and running till the end of the week :frowning_face:

I’m checking with the team. So far it seems the fixes are all the server side, so couldn’'t work around the issue on the device’s side. But we are investigating further and keep you posted.

Do you mind if we ask what are you working on that you want to finish this week? Would a sort-of workaround be using the QEMU 64 bit device type? (a virtual device) If you deploy some applications onto that, pretty sure would work on the NUC when the VPN fix is released. Depending what’s your project specifically.

If we have any news in the meantime still this week, will let you know for sure!

Hi imrehg.
Thank you very much for your help and support.

I’m working on a small electron app that uses a USB camera and manipulates
the stream.

This project is for a small business that has a reopening event on this
Sunday.

I’m not familiar with the QEMU 64, can I perform remote actions on the nuc
from a virtual machine? (If I restart remotely, the nuc will boot
automatically into the virtual machine and launch the electron app?

I see, if there are external peripherals, not sure if the QEMU image would work for you. The idea for QEMU is that you can just run a “virtual device” on your development machine, and develop on that. I see that you are saying running the QEMU image on top of the NUC, that would probably overcomplicate things, and not sure if it would work.

Would this device stay in use after Sunday or it just have to work through that event?
Asking because one idea is that we are planning to deploy the proposed fix to our staging environment at https://dashboard.resinstaging.io/ I will have to confirm with the team, but if the fix is deployed there (likely tomorrow morning European time), then you can set up your device as a staging device, and get this weekend done, and when the fix is released in production, then reporovision your device on production. (This later change is needed because staging is not guaranteed to work at any given point, it is used to test upcoming features). Would this be likely to get you through this project now?

My colleagues are saying that the fix should be deployed on https://dashboard.resinstaging.io/ could you it out, register there, and provision a NUC from that dashboard? That would also confirm for us whether or not the fix works for you!

Just flashed the new staging img and it worked!
The device appears as connected.
Thank you vary much for your help!

Now i’m having a hard time with git push -> Build failed

Hey @Doise was just wanted to update you, that we got the fix in the VPN (as of 5 minutes ago:), so now production should work too, would recommend retrying that! Sorry for sending you this way and that, just wasn’t sure when it will be ready, was sooner than I expected.