This has happened to me 3/3 installs, I’ve lost 2 days already and still no ollama running, has anybody found a way?
we’re at over two months out on this issue that basically bricked the jetsons, this is INSANE!
Please release an image that is working at the VERY LEAST.
Instead of re-flashing I chose to buy another micro SD card. Now I have two setups. If you want to switch projects it is handy.
@AastaLLL & All,
I am considering updating Ubuntu packages, since there are many in the queue.
Using the method described earlier to hold specific packages after reflashing the Jetson by the SDK, are these all that is required to prevent the CUDA0 buffer error?
I am going to add as follows.
Thanks
sudo apt-mark hold linux-firmware
sudo apt-mark hold nvidia-l4t-firmware
sudo apt-mark hold nvidia-l4t-xusb-firmware
sudo apt-mark hold nvidia-l4t-display-kernel
sudo apt-mark hold nvidia-l4t-kernel
sudo apt-mark hold nvidia-l4t-kernel-dtbs
sudo apt-mark hold nvidia-l4t-kernel-headers
sudo apt-mark hold nvidia-l4t-kernel-oot-headers
sudo apt-mark hold nvidia-l4t-kernel-oot-modules
Can we expect the fix still in this year or by the end of the next (maybe?!) or this is just a wishful to ask for it?
At this stage, at each sprint iteration, we have plenty of material to present our work in a joyful…
These units are still being sold and are unusable for their intended purpose for MONTHS now.
If it is really this difficult to fix, then at least release a WORKING IMAGE with utilities installed and auto-updates that break them DISABLED!!!
The ISO-image on your server is a good option, but it needs some updates to be able to run and install Ollama and by now has other updates in the ever increasing list that breaks proper functioning…
Hey everyone,
Like a bunch of you, my Orin Nano’s toast after those JetPack security patches for CVE-2025-33182 and CVE-2025-33177. Ran the usual apt upgrade, and bam – “unable to allocate CUDA0 buffer” error kills any Ollama or CUDA work. Total downtime killer.
NVIDIA, this is on you: shoving out half-baked fixes without real testing or heads-up, breaking core GPU stuff on your own hardware. Morally? It’s crap – you’re ditching the community that relies on this gear, prioritizing rushed patches over stable dev workflows. No excuses for a giant like you.
Fix it fast, roll out proper patches, and comp us for the lost time (credits, whatever). If not, EU users like me have no choice but to lawyer up under the 2024 Product Liability Directive – strict liability for defective software means you pay for the harm.
Who’s in? Let’s document our issues and push back hard. NVIDIA staff, ball’s in your court.
I totally agree with the college, i am also from EU.
@AastaLLL when the fix will be rolled out.
I also am having this issue - I’m open to letting someone from Nvidia remote or ssh into my device to see what’s going on if they can verify they work there (admin status)
After marking the kernel, will we be able to unkock it once fixed? Without having to reset the device again?
Hello, any updates on the fix? I have a new Jetson nano and seeing the same issue. I am trying to train the 124M GPT2 model.
Hi, @all
We have fixed this issue. Internal review and testing are also done.
But the fix includes an upstream patch that needs extra reviewing, so it needs some time to release the solution.
Currently, you can get the fix via building a custom kernel with the following instructions.
Please note that the upstreaming patch (a94ca4c.diff.zip) might change during the upstream review process.
Download source
-
public_sources.tbz2
https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v4.4/sources/public_sources.tbz2 -
Changes: (please unzip the files to *.diff files)
7959247.diff.zip (1.7 KB)
a94ca4c.diff.zip (1.2 KB)
b27a1a7.diff.zip (1.5 KB)
cfe6242.diff.zip (3.3 KB)
e488812.diff.zip (2.0 KB)
Unpack source
$ tar xf public_sources.tbz2
$ tar xf aarch64--glibc--stable-2022.08-1.tar.bz2
$ cd Linux_for_Tegra/source/
$ tar xf kernel_src.tbz2
$ tar xf kernel_oot_modules_src.tbz2
$ tar xf nvidia_kernel_display_driver_source.tbz2
Apply changes
$ cd Linux_for_Tegra/source/kernel/kernel-jammy-src/
$ patch -p1 < [/path/to/a94ca4c.diff]
$ cd ../nvidia-oot/
$ patch -p1 < [/path/to/cfe6242.diff]
$ patch -p1 < [/path/to/e488812.diff]
$ patch -p1 < [/path/to/b27a1a7.diff]
$ patch -p1 < [/path/to/7959247.diff]
Build kernel
$ cd ../ # back to Linux_for_Tegra/source/ folder
$ export CROSS_COMPILE=$PWD/../../aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-
$ make -C kernel
...
================================================================================
Kernel Image: [path/to/Linux_for_Tegra/source/kernel/kernel-jammy-src/arch/arm64/boot/Image]
Kernel sources compiled successfully.
================================================================================
$ export INSTALL_MOD_PATH=<install-path>/Linux_for_Tegra/rootfs/
$ sudo -E make install -C kernel
$ cp kernel/kernel-jammy-src/arch/arm64/boot/Image <install-path>/Linux_for_Tegra/kernel/Image
Build nv-oot
$ export CROSS_COMPILE=$PWD/../../aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-
$ export KERNEL_HEADERS=$PWD/kernel/kernel-jammy-src
$ make modules
================================================================================
Display driver compiled successfully.
================================================================================
$ export INSTALL_MOD_PATH=<install-path>/Linux_for_Tegra/rootfs/
$ sudo -E make modules_install
$ cd <install-path>/Linux_for_Tegra
$ sudo ./tools/l4t_update_initrd.sh
Flash
Please follow the document below to flash the system:
After flashing the device with the custom kernel, please mark hold the kernel to prevent it from being overwritten by the r36.4.7.
$ sudo apt-mark hold nvidia-l4t-display-kernel nvidia-l4t-kernel nvidia-l4t-kernel-dtbs nvidia-l4t-kernel-headers nvidia-l4t-kernel-oot-headers nvidia-l4t-kernel-oot-modules
Once the official release is ready, you can unhold these packages to get the fix without reflashing.
Thanks.
Giving this a shot and will update you how it goes. Thank you all for your continued attention to this matter.
Can you provide the patches for 35.6.2?
Thanks
The fix may work, but the way it is provided is not practical for normal users. Building and flashing a custom kernel is complex, risky, and not suitable for production systems, especially since the problem was caused by an official security update.
Because of this, I prefer to wait for the official Jetson Linux image or package release. Once the fix is officially released and supported, I will update through the normal update process instead of using a custom kernel.
I assume at some point I can just sudo apt update && sudo apt upgrade and everything will work again?
That’s how I got here, so that’s how it should be resolved. Please stop making me jump through hoops to fix your mistake.
Follow up question: It appears you’re doing a lot of QA/QC for the fix patch, was this done for patch 35.6.2?
It depends on what you mean by a normal user - this is a development board not a “finished” consumer product. Plus, what I’ve found through implementing this fix is that building a custom kernel like this might be the basis of successfully porting the Nvidia proprietary kernel to the Arch userspace (and thus de-debianizing the Jetson). Maybe it wasn’t about the fix, but it was the friends we made along the way
until it they release another poorly tested update, then you have to do it all over again. I understand how dev boards work, doesn’t have to be that way.