Hello,
I’m posting this to share learning, much of which will probably be in the “Captain Obvious” category for engineers and enthusiasts that work with HPC/AI/Linux technology 25/7.
Quick background - I’m from a bygone era of Unix, VMS and other large-scale system architectures that today’s burner phones can outperform before they power-up. While I dabble in modern tech and YouTube daily (learning just enough Linux and python to make me dangerously incompetent with Ollama, LMStudio, N8N and other buzztools), I am prone to getting cut on the edge instead of actually cutting it.
That background out of the way, here’s what I’ve learned (and some ‘what I wish I had known’) insights with my DGX Spark so far, in no particular order except perhaps a relative timeline, and not a prioritized list of learnings. I’m sure a lot of this may fall into the “noob” perception, so if that kind of commentary isn’t a value-add, please skip to the next posting in your to-read list.
-
The first-time power-up Bluetooth experience will apparently have the DGX Spark latch on to the first thing that identifies as a keyboard. If (like me) you have a DaVinci Speed Editor in range (which identifies as a keyboard), you’ll suddenly face hours of fun trying to complete your setup using a video editing wheel, or desperately trying to find a wired keyboard and mouse. Since the DGX Spark thinks a keyboard has been connected and has satisfied the first-time pairing opportunity, I couldn’t easily put the DGX Spark back into pairing mode. (I thought about trying a command-line alternative to reactivate bluetooth pairing via an SSH session, but that was outside the scope of the NVidia support documentation I could find, and while I have a good idea how to do it in vanilla Ubuntu, I wanted to stick as closely to the NVidia instructions as much as possible for the first few moments / hours.)
-
When you find a wired keyboard and mouse, they’ll likely have USB-A connectors. Assuming you have USB-A to USB-C adaptors (I did), you’ll quickly learn that unless they’re dongle (cable) adapters, the housing on most non-dongle adaptors are too large to be plugged in next to each other on the back of the DGX Spark. Since the USB-C slot next to the power button is taken up with the power supply, this means it’s really difficult to plug both a keyboard and mouse into the DGX Spark unless both have non-adaptored (is that a word?) USB-C connectors. Fortunately, I had an old Dell keyboard which doubled as a USB-A hub, so I was able to chain the mouse to the keyboard and use only one slot on the back of the DGX Spark. From there, I was able to reactive Bluetooth pairing, disable the DaVinci Speed Editor, and add a Logitech keyboard and mouse.
-
Remote Desktop access is difficult for…reasons? I access the vast majority of systems in my homelab remotely, so I know my way around RDP and VNC tools sufficiently to function (including the headaches Raspberry Pi owners face with the “Wayland” issue). While the standard Ubuntu menu options for enabling Remote Desktop and Remote Login access were exactly where I expect to find them in NVidia OS, the Remote Login feature incorrectly renders the output into an interlaced, vertically-wrapped mess. From what I was able to find searching on these symptoms independent of any reference to the DGX Spark, I found identical examples which fit into a larger category of Gnome issues (specific to Remote Login functionality). I found some solutions contributed by individuals that involved recompiling NVidia specific libraries with nvcc and specifying specific architectures, however, they were specific to 30-series and 50-series architectures. I was rapidly finding myself outside my depth (at least in terms of how much time I wanted to try and solve this specific problem). I am currently looking into installing XRDP (which is a common solution from what I’ve discovered so far), but where that’s outside of NVidia’s recommendations (at least that I can find so far), I still wanted to look at NVidia-supported alternatives for remote access, which leads me to my next learning…
-
Some of NVidia’s remote access/development tools don’t install successfully on differing X86 platforms. I decided to install NVidia Sync and NVidia AI Workbench on two of my Windows 11 Pro workstations. NVidia Sync installed successfully on both systems. On one system (a Strix Halo-based mini PC with an existing WSL2 and Docker configuration), NVidia AI Workbench fails to install (saying only that there is a problem, and to try and reinstall again). On the other system (an Intel NUC with built-in Intel graphics, and no pre-existing WSL or Docker configurations), the installation worked right out of the gate. At this stage, I really would rather get an RDP-based functionality up and running on the DGX Spark and keep all of my development, testing and publishing confined to that system, rather than add a layer of abstraction complexity that I have limited time to manage. Before making changes to the DGX Spark outside of the NVidia recommended experience, I wanted to make sure I had proper backup and recovery procedures and assets in hand, which led me to the next learning…
-
Backup and Recovery on the DGX Spark is different than I would expect in other (production) systems. Having read ahead in the NVidia forums and seen posts such as “I loaded a 65GB model and now my DGX Spark won’t boot” and other examples where in the first 24 hours, numerous other DGX Spark owners are having to go through system recovery efforts, I wanted to get ahead of that potential timeline and put together a recovery USB stick, and set up a backup plan to preserve my system (not just my individual files or work) the same way I would in a Windows or FreeBSD environment. I was able to follow NVidia’s documentation to the recovery download and created a USB recovery key. However, when looking at the situation for backups, all I can initially find within NVidia OS is Deja Dup Backups which seems to focus just on individual user files and not preserving the system as a whole. I’m looking at other tools (or creating my own set of scripts) to do complete backups of the DGX Spark before proceeding to go through the lessons and frankly amazing examples shown on the DGX Spark | Try NVIDIA NIM APIs page, given that I’m seeing posts from others that are running into (in some cases) bricking scenarios, which gives me concern.
-
System updates from a web page instead of a command line. The NVidia documentation emphasizes that updates should be preferentially performed through the DGX Dashboard instead of a typical “sudo apt update” chain. I was surprised to see this as part of my random startup experience within the system instead of as a highlighted recommendation in the something like the Quick Start guide (maybe I missed it). There will be tools and other 3rd-party functions I could see installing on the DGX Spark that as part of their own recommendations, recommend the “sudo apt update” and upgrade chain as part of their installation processes. Should command-line updates be avoided at all costs? Do command-line updates void the warranty? Again, maybe I’ve missed something, but this seems like a very significant exception to what is otherwise standard (or at least expected?) Linux distribution maintenance.
At some point, I do hope to actually be loading and tuning models, and put a few agents to work. ;-)
I hope these individual insights were helpful. Thank you for your time.