Ensured to have a working ethernet connection and waited 5 minutes before getting trapped in the “Connect To Wi-Fi” situation.
Tried the tether workaround with several androids and Iphones
Confirmed the time in the BIOS to be correct
At this point I am just baffled by how terrible the experience is for such an expensive piece of hardware. Why not let the user choose how to handle networking? Can I jump into a root terminal to fix this?
Even the most general user-friendly Linux distro will somehow allow you to walk a LAN path, enter a static IP, or choose to connect over ethernet, but here someone thought it would be intelligent to lock the user into a wifi path that is broken…
So my next question is: how do I make this $10k piece of hardware go past initial setup? Because this is maddening, and so far that money is wasted!
Yep, following this too as I’ve also done these steps. Completely maddening to not have a command-line option here. My DHCP server has allocated it an address on the ethernet interface…
I’m also having the same issue now with my 3rd spark. The initial setup was never smooth, but it’s the first time I’m experiencing connectivity issue.
I wonder if some service on nvidia side is down that Sparks pings to confirm the connection? Because I can see it getting DHCP addresses for both wired Ethernet and Wi-Fi.
The fact that NVIDIA’s guide says setup depends on downloading updates during first boot, and that unstable connections are discouraged, kinda reinforces that the setup path is tightly coupled to external validation/update services.
I had the same issue when I bought my new Gigabyte AI Top 2 days ago and I couldn’t connect to any WIFI’s or Ethernet and I end up downloading an ISO from the manufacturer and used Rufus to boot to USB and re-installed the OS and I was able to reconnect to the WIFI without any issues and it also downloaded the latest updates and no issues
So, apparently, connectivity-check.ubuntu.com resolves to a multiple IP addresses, most of which seem to be down. I finally set up a DNS resolver override on my router to point it to 91.189.91.96 and got past initial setup screen.
I did prepare a recovery USB with the patch referenced above, but managed without it.
Thanks eugr, this worked for me. That specific IP didn’t but I set up LAN DNS to resolve the connectivity domain to an unrelated IP that I knew would return 200 and that did it.
Per NetworkManager.conf man page, when checking online connectivity the application is expecting a x-networkmanager-status: online response from http://connectivity-check.ubuntu.com.
From another system check if it works. Output should be like this:
If you don’t get the online status your installation will fail, so check network connectivity to Ubuntu’s server before starting the installer.
The patched solution will make HasInternet() always return true fooling the installer to proceed. But it requires some involvement from the user to apply it.
Canonical acknowledged the issue, and looks like it’s fixed already. It works from my location.
It looks like it also tries https request too. I tried to emulate this on one of my local servers and redirected DNS to it, and I’ve seen successful attempts from my new spark, but it still didn’t work. What did the trick for me was redirecting to one of the working IP addresses so https could work too.