Extending the conversation from the Unable to Allocate CUDA 0 Buffer thread, the release of 6.2.2 and r36.5, which was supposed to solve the issues associated with this, actually ended up breaking the relationship between Jetson Linux and the Snapd package manager (among other things). The error associated are Snapd errors when trying to open basic applications like Chromium browser or use Ollama. Applications aren’t able to launch at times, or launch with graphical artifacts and lagginess. There are also signs of “flickering” in the screen when you make an application take up a full window. I’ve reflashed my device’s nvme from a machine natively running ubuntu Jam Jelly about 3 times now and have gotten the same results. I found a reddit post where people have talked about this issue as well, for more information on what people are experiencing: Reddit - The heart of the internet
My suggestion on this one would be to rebuild “Jetson Linux” entirely from Debian (as the Jetson project seems to rely on upstream/stable builds) and either rely on a more universally applicable package manager like APT, or create your own to securely release your packaged builds. This relationship with Canonical, where one company is constantly breaking the updates of the other, is a sign that one hand isn’t talking to the other in the development process. Nvidia needs to take a more hands on relationship to managing Jetson linux outside of just JetPack and the kernel.
I do not know how to customize a snap environment, but it is a container. I suspect that if the container makes an assumption related to memory, and the memory on the Jetson itself does not match this view (e.g., it doesn’t know memory regions reserved for GPU), then it might behave oddly (“badly”). If your application runs in snapd, then I suspect it won’t run your application any better in Debian versus Ubuntu (assuming you are reserving memory regions the same way; Debian and Ubuntu are more or less similar aside from the GUI and a few other details).
What I’ll suggest is that if you’ve received information reserving a memory region for the GPU, then you will want to find someone who develops under snap and ask them how that physical memory mapping might be conveyed to the application in snap.
Of course the other alternative, which often is not available, is to use a native app without snap.
@AastaLLL I went to the link you provided and rebuilt the new kernel as instructed, then installed snapd - we have seen an 'improvement’ but we’re not at 100%. Chromium at least opens now, but it stutters upon opening and is buggy. Ollama loaded in the terminal so that’s also an improvement, but I haven’t pulled a model yet to try it so I will report back with the results now that I can at least access the Nvidia forum from the Jetson via a working browser
Hi,
Thanks for the feedback.
Is your use case working normally after rebuilding the kernel?
Thanks
After a kernel rebuild, snap apps are buggy but they at least open and Ollama via the terminal does produce output even on larger models like QwenCoder 2.5 7b (quantized). This made me look for options other than Jetson Linux because I wanted something that just worked predictably out of the box, so after some research I started using Anduril’s JetPack NixOS ( GitHub - anduril/jetpack-nixos: NixOS module for NVIDIA Jetson devices · GitHub ) and (after learning some Nix) that’s been a smoother experience to get to what I needed (as well as for AI workflows that use the Nix package manager). I would research what they’re doing over there because it works out of the box (even if it does requiring learning Nix, or simply building some Nix macros)
Hi,
About the issue of snap app, could you file a new topic and share more details about it?
We want to check it further.
Thanks.