Setup Wizard loop

Device: MSI C931 EdgExpert-C594
OS: Nvidia DGX OS GA2 OTA2
Network Environment: UniFi Dream Machine SE & US XG 6 PoE Switch
Location: Auckland, NZ

Fresh out of the box, I am stuck in the initial setup wizard. Even with a 10GbE RJ45 cable connected before boot and assigned IP on Port via DHCP, the installer fails to “Skip” the Wi-Fi selection screen.
I choose (language/ region, accept terms, create user/ pw) but the next screen “Connect to Wi-Fi” fails to proceed to next step. When attempting to join any Wi-Fi network (including mobile hotspots), it returns “Unable to join. Fail to join the network. Please try again.”

Despite the UI saying there is no connection, the backend is clearly online:
* I can successfully ping the unit (10.0.10.5) from my desktop with 3ms latency.
* The UniFi dashboard logs confirms a stable 10GbE Full Duplex link on Port 2 (VLAN 10).
* UniFi “Latest Flows” shows the device successfully reaching connectivity-check.ubuntu.com and dashboard.snapcraft.io via HTTPS.
* System clock/ date is verified correct. IPv4 is visible but shows “Configured: Disabled” in the UEFI Network Stack, while the OS has clearly grabbed a DHCP lease.

Attempting to drop to a TTY (Ctrl+Alt+F2) triggers an immediate system reboot.

Lastly i tried installing the latest OS release “Nvidia DGX OS GA2 OTA2”.

Any support on how I should test this issue further, currently have an expensive paperweight on my desk for 3days now.?

It looks like server side validation issues. Even employees are reporting the same issue:

Are you sure you’re able to reach curl -v https://connectivity-check.ubuntu.com?

No, I can’t confirm that from the DGX itself because OOBE locks out shell access. What I can confirm is that the box gets an IP, is pingable, and attempts outbound connections to Canonical/ Snapcraft endpoints, yet the setup still fails.
I’ve reproduced the same exact behavior over Ethernet, multiple SSIDs/VLANs and a mobile hotspot. This no longer looks specific to my UniFi network.
Given the number of parallel reports in the forum, seems like this is an connectivity-validation issue on the device or server side.

very fustrating

I’ve got a workaround until they fix it eventually.

Do you have other Linux machines that you’re using to write the recovery USB?

Yes, I have other Linux machines I can use to write to the recovery USB. I noticed the recovery docs reference some kernel boot parameters: usb.shell, noui, and autoinstall.

I’ve pushed a script up, should be pretty seamless to patch the current recovery image.

https://github.com/sjug/dgx-spark-ethernet-patch

I’m experiencing the same issue.

Still unable to pass through this problem.

I can confirm after following the steps in your repo, my spark device proceeded downloading and installing the system updates. much appreciated

It seems the check is fixed by Canonical :)
For me it works without a patched ISO.

xxx@MacBook-Pro-von-xxx ~ % curl -v https://connectivity-check.ubuntu.com
* Host connectivity-check.ubuntu.com:443 was resolved.
* IPv6: (none)
* IPv4: 91.189.91.96, 91.189.91.97, 91.189.91.98, 185.125.190.98, 185.125.190.96, 185.125.190.97
*   Trying 91.189.91.96:443...
* Connected to connectivity-check.ubuntu.com (91.189.91.96) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=connectivity-check.ubuntu.com
*  start date: Jan  8 08:13:33 2026 GMT
*  expire date: Apr  8 08:13:32 2026 GMT
*  subjectAltName: host "connectivity-check.ubuntu.com" matched cert's "connectivity-check.ubuntu.com"
*  issuer: C=US; O=Let's Encrypt; CN=R12
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://connectivity-check.ubuntu.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: connectivity-check.ubuntu.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: connectivity-check.ubuntu.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 204
< x-networkmanager-status: online
<
* Connection #0 to host connectivity-check.ubuntu.com left intact

I’m in Thailand, and it still doesn’t work.

* Host connectivity-check.ubuntu.com:443 was resolved.
* IPv6: (none)
* IPv4: 185.125.190.97, 91.189.91.97, 91.189.91.96, 185.125.190.96, 185.125.190.98, 91.189.91.98
*   Trying 185.125.190.97:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /opt/anaconda3/ssl/cacert.pem
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=connectivity-check.ubuntu.com
*  start date: Jan  8 08:13:33 2026 GMT
*  expire date: Apr  8 08:13:32 2026 GMT
*  subjectAltName: host "connectivity-check.ubuntu.com" matched cert's "connectivity-check.ubuntu.com"
*  issuer: C=US; O=Let's Encrypt; CN=R12
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to connectivity-check.ubuntu.com (185.125.190.97) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://connectivity-check.ubuntu.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: connectivity-check.ubuntu.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.12.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: connectivity-check.ubuntu.com
> User-Agent: curl/8.12.1
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Recv failure: Connection reset by peer
* OpenSSL SSL_read: Connection reset by peer, errno 54
* Failed receiving HTTP2 data: 56(Failure when receiving data from the peer)
* Connection #0 to host connectivity-check.ubuntu.com left intact
curl: (56) Recv failure: Connection reset by peer

For me it is also broken again.

Dont return your expensive paperweights yet as i was to do after few frustrating hours … but then the hero appeared = Huge thanks to @sjug — his patch inspired me to do the hard work :) and ask AI to give me manual steps to follow because i have oem lenovo PGX and his patch wouldnt work for me

In my case, what worked was this:
I used the Lenovo OEM recovery image
Before first boot, I stopped there
I had Secure Boot disabled (at least in my case, because I was using Ventoy)
I booted Ubuntu Desktop for ARM64

From the live system, I found and mounted the installed root partition, then patched the installed oobe-service
After reboot, the Wi-Fi/setup loop was gone and the machine booted normally and updated via ethernet (network uses dhcp)

I only tested this on a fresh install before first boot, and that worked for me. I’m not sure whether everyone needs to reflash/reinstall first, or whether this also works on an already booted “broken” system.

Steps I used from the live ubuntu system:

sudo su
lsblk -f

Replace /dev/nvme0n1p3 below with the real root device you found.

Mount the installed system:

mkdir -p /mnt/target
mount /dev/nvme0n1p3 /mnt/target

Check that the target file exists:

ls -l /mnt/target/opt/nvidia/dgx-oobe/oobe-service

Back it up and verify current bytes:

cp /mnt/target/opt/nvidia/dgx-oobe/oobe-service /mnt/target/opt/nvidia/dgx-oobe/oobe-service.bak
od -An -tx1 -N8 -j3999512 /mnt/target/opt/nvidia/dgx-oobe/oobe-service | tr -d ’ \n’; echo

Expected before patch:

ff3b00f9ffdf0039

If you see anything else, stop.

Apply the patch:

printf ‘\x20\x00\x80\x52\x4d\x00\x00\x14’ | dd of=/mnt/target/opt/nvidia/dgx-oobe/oobe-service bs=1 seek=3999512 conv=notrunc status=none

Verify the patch:

od -An -tx1 -N8 -j3999512 /mnt/target/opt/nvidia/dgx-oobe/oobe-service | tr -d ’ \n’; echo

Expected after patch:

200080524d000014

Unmount and reboot:

sync
umount /mnt/target

useful link when you are on live system:

I used the Asus DGX OS recovery image and had the same problem, I had the LAN connection but it still asked for a wifi connection, tried with 2 local wifi networks and it did not work, then created a hotspot from the phone and not worked. The final solution was to just leave it for about half an hour (searching online for solutions) and somehow when I looked at the screen the setup continued. Weird.

So, apparently, connectivity-check.ubuntu.com resolves to 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 @sjug patch, but managed without it.

I had this issue as well. Brand new $3.5K Asus GX10 that was pretty much a brick. I called Asus support and they were no help, they told me “you can bypass using your Microsoft account” LOL 🤣. They said they are escalating and I will hear back from them. No need to now because the issue is fixed!

I actually fixed it twice, once on the 1TB factory SSD, then again on a 4TB SSD I bought separately.

On the 1TB default drive:

  • I first tried to boot it up and access via Wi-Fi, but there was no Wi-Fi connection emitted from the unit.
  • I had it connected to ethernet and power
  • I then plugged in my Macbook’s external monitor to it via DP, then ran into the Wi-Fi loop (can’t connect to a network even though it sees them and the password is correct)
  • I reinstalled the OS (NVIDIA DGX OS for ASUS Ascent GX10 7.4.0-3) from the official Asus download page.
  • BIOS screen won’t display on DP, so I had to use an HDMI monitor
  • After the Asus OS reinstall the issue persisted
  • I installed NVIDIA system recovery but issue still persisted
  • When stuck on the Wi-Fi loop page, I unplugged the ethernet cable and got a weird password login modal greyed out thing
  • I pressed “x” on the password modal when it was greyed out, then plugged in the ethernet, then it searched for a “Wi-Fi” network, still failed
  • I did the unplug and plug in ethernet thing a few times, then it finally went in to setup mode and I was able to boot and log in

On the 4TB:

I figured since I was going to install the 4TB SSD I can just do the same and return the drive cloner I bought. So I proceeded to try the same thing as above after I installed the 4TB SSD. It didn’t work, I couldn’t get pass the Wi-Fi looping page. I then tried @sjug‘s DGX Spark Recovery patch and it worked! THANK YOU @sjug ! Note: you need to patch the recovery file on a Linux machine. Good thing I had a UTM Linux VM already installed.

What an ordeal, I spent a whole day and a half working on this. Maybe the GB10 box manufacturers need more humans in the loop in the QA process. I’m guessing they are relying too much on AI now! 🤣

There was a temporary degradation in Canonical’s servers which may have interfered with some units setup.

Canonical has confirmed that the issue has been resolved. Thank you for your patience.