I understand Windows, macOS and Ubuntu are the only supported operating systems for AI Workbench but Linux Mint is based on Ubuntu 24.04. Here is the output of uname on my fresh Linux Mint 22.1 installation:
Linux <node_name> 6.11.0-17-generic #17~24.04.2-Ubuntu SMP PREEMPT_DYNAMIC Mon Jan 20 22:48:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Despite clearly identifying as Ubuntu 24.04, the installer immediate fails after clicking “Begin Installation” (with no error message, by the way). This seems like an overly stringent OS check. What’s up with this?
Please tick the appropriate box to help us categorize your post
Bug or Error
Feature Request
Documentation Issue
Other
Call it a bug or call it a feature request. I do not understand why this does not work.
Thank you,
Elliott
Hi Elliott,
Sorry that you are having trouble.
The install has some simplifying assumptions baked into it, so if it doesn’t find what it wants it will fail. I’m assuming that Mint has some difference from Ubuntu even though it is derived from it.
There should be a log file that will record where the install failed.
Can you use the instructions here to find the main.log and then send it to aiworkbench-support@nvidia.com?
Please make sure to include a link to this post in that email.
Thanks,
Tyler
Hi Tyler,
Sent on 2/15. No response yet.
Thank you,
Elliott
Hi Elliott
I just searched and didn’t see an email from you.
Tyler
Hi Tyler,
I sent the following message multiple times to aiworkbench-support@nvidia.com as well as to you directly.
I have attached main.log. I tried to install twice which seems to be reflected in the log. The first time I tried to install by just clicking on the file through the GUI (after I changed permissions). The second time, I tried to install from a shell. This produced the output I attached. I see a few issues.
• It appears the installer tried the following: error linux Command failed: cat /etc/*-release
This will fail on Mint for two reasons.
◦ Besides for the file “os-release” which I assume is the actual target of the check, there is a directory “/etc/upstream-release” as well as a file “lsb-release” in /etc. So, IMHO, this test is lazy and should specifically target the appropriate file name.
◦ Although “uname” output clearly identifies the system as running Ubuntu, the “os-release” file (as well as the “lsb-release” file) do not.
If Mint is too different from Ubuntu, that’s fine. I just would like to understand this especially if it might enable the use of a Linux release some users may prefer (e.g. me 😊).
Which leads to another question: I noticed that Ubuntu has a Cinnamon “flavor”. Do you know if this will work or do I have to use the default Ubuntu release?
Attachments:
main.log (204 Bytes)
uname_output.log (132 Bytes)
AI_Workbench_Installer_Output.log (13.3 KB)
(Limited to 4 links by the forum. More attachments to be posted next.)
Thank you,
Elliott
Additional attachments.
lsb-release.txt (105 Bytes)
os-release.txt (379 Bytes)
Thank you,
Elliott
Elliot.
Sorry. Super slammed and many fish to fry.
We will be moving into a world of greater flexibility around Linux distros, but not at the moment.
For the moment, would you mind just defaulting to vanilla Ubuntu to use Workbench?
Understood it’s not your preference, but we don’t have bandwidth to address this immediately.
I will hit you on email to setup a time to chat.
Tyler
Thank you to anyone taking a moment to read this. This has been sitting a while and I am guessing everyone at NVidia is busy with many things. This post is an attempt to assist, streamline, and hopefully accelerate a fix for this. To a developer familiar with the code, this is a quick fix after reading the below. Should be able to knock this out in about an hour… And.. It looks good on a status report.. ( I made our AI Workbench app compatible with over 6 different Linux distributions that it wasn’t previously compatible with more than sextupling it’s current compatibility) :-)
Recommendations to NVIDIA (to make Workbench Mint-compatible and at the same time compatible for other Ubuntu based distributions)
The OS check has a genuine bug plus an over-narrow allow-list. Suggested fixes,
easiest first:
-
**Don’t treat a non-zero exit of `cat /etc/*-release` as “no OS info.”**
The `execa`/`_n` wrapper discards `stdout` when the exit code is non-zero. On
any system with a directory matching `/etc/*-release` (Mint and other
Ubuntu-derivatives ship `/etc/upstream-release/`), `cat` exits 1 *with valid
stdout*. Either run `cat /etc/*-release 2>/dev/null || true`, or read the
error object’s `stdout`, or set `reject:false`. **This one-line change alone
makes the current check work on Mint** (because Mint’s upstream lsb-release
already says `DISTRIB_ID=Ubuntu` / `DISTRIB_RELEASE=24.04`).
-
**Stop OS-detecting via `cat` + substring matching.** Parse
`/etc/os-release` properly and honor `ID_LIKE`. Mint reports
`ID=linuxmint`, `ID_LIKE=“ubuntu debian”`, `UBUNTU_CODENAME=noble` and
`VERSION_CODENAME=zena`. Accepting `ID=ubuntu` **or** `ID_LIKE` containing
`ubuntu` (and mapping `UBUNTU_CODENAME`/`VERSION_CODENAME` to the supported
release) covers Mint, Pop!_OS, Zorin, elementary, KDE neon, etc.
-
**Gate on capability, not brand.** What matters is glibc/kernel/Podman/driver
compatibility, not the distro name string. Consider a documented
override (e.g. `NVWB_SKIP_OS_CHECK=1` or a supported-distros config) so
binary-compatible derivatives can opt in.
-
**Make the failure actionable.** “osNotSupported” gave no reason. Log the
detected `ID`/`VERSION_ID`/codename and what was expected.
Hi Joe. Thank you for taking the time to figure this out and post it here.
And yes, we are super busy but I need to be better about responding here and following up.
The “historical” reason for the blocks on alternate distros is based on test coverage, which is quite large already across multiple versions of macOS and Windows. Another reason is the NVIDIA AI Enterprise license support we provide, which has SLAs that compound the first issue to some extent.
However, I do want to enable users to “go off the beaten path” for distro support which would align the with gating on capability approach you mention.
So, a few questions:
- Are you doing this for the Desktop App, for the “remote install” or both?
- For the cases where you did “after market modifications”, were there any downstream effects as far as you can tell in the UI/UX or capabilities?
I am doing this for the Desktop App for the remote install. I have a dgx spark and it was one of the apps to setup. I was able to connect to the dgx spark and start the tutorial.
Full local setup didn’t work. The application didn’t say it is because I don’t have an nvidia device / drivers loaded, but I think that may be the case. Another bug possibly (At least the error message should be descriptive enough…) More detail— The service install fails and it just asks to retry. If I copy the command it says nvidia-smi couldn’t run (It isn’t installed.) Installing it and running it just says it can’t communicate with the driver. Probably a good idea to capture that or let someone new like me know that the remote install is all I need??? I think an install on my same hardware with plain ubuntu would result in the same situation.
Remote connection to the spark works fine with no errors.