[SOLVED] - NVIDIA 580.x + Kernel 7.0 incompatibility on T...

Has anyone got any idea for my seeminly hopeless situation with nvidia drivers on the proxmox host?

Hardware: GTX 1060 (Pascal) + GTX 180 Ti (Kepler)
PVE version: 9.1.2

The problem: Nvidia Driver 580.x is the last series supporting Pascal/Kepler hardware.
It builds fine on kernel 6.17 but since proxmox updated to kernel 7.0 it fails due to VMA locking API changes (VMA_LOCK_OFFSET removed, __is_vma_write_locked signature changed in mmap_lock.h).

The repositorys

The debian12 CUDA repo has 580.x but is signed with a SHA1-bound key, which trixie's sqv rejects since Feb 2026
The debian13 CUDA repo has working signing but no 580.x, only newer driver series that dropped Pascal/Kepler support
The debian 13 repo has only driver 550 which is too far outdated and I had issues with it

What I think to do:
Pin the kernel to 6.17.13-7-pve and held kernel 7.0 packages, but due to exploits, I don't really wanna do that?
Also what would be the suggested way to do this?

Is there a patched 580.x build anywhere that supports kernel 7.0's new VMA API?
Is there a plan for the debian13 CUDA repo to carry 580.x for legacy hardware?
Any other suggested approach for Pascal/Kepler on PVE trixie long-term?

Last edited: May 10, 2026

Try this parameter in the nvidia apt repository configuration for SHA1 problem:

Last edited: May 11, 2026

@czechsys

Thanks, I tried with that parameter and got the following error:

Code:

Err:5 https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64  InRelease
  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on EB693B3035CD5710E231E123A4B469963BF863CC is not bound:            No binding signature at time 2026-05-08T15:21:05Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Hit:7 http://download.proxmox.com/debian/pve bookworm InRelease
Warning: OpenPGP signature verification failed: https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64  InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on EB693B3035CD5710E231E123A4B469963BF863CC is not bound:            No binding signature at time 2026-05-08T15:21:05Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Error: The repository 'https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64  InRelease' is not signed.
Notice: Updating from such a repository can't be done securely, and is therefore disabled by default.
Notice: See apt-secure(8) manpage for repository creation and user configuration details.

after also adding trusted: yes I got only a warning:

Code:

Warning: OpenPGP signature verification failed: https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64  InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on EB693B3035CD5710E231E123A4B469963BF863CC is not bound:            No binding signature at time 2026-05-08T15:21:05Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

After this I was able to update just fine, thanks a lot!

I ran into a similar issue with the Debian-packaged 550 driver rather than 580. I put together my patch approach here in case it helps anyone else:
https://github.com/egeekial/nvidia-550xx-dkms-proxmox

It’s specifically for `nvidia-current` 550.163.01 on the Proxmox 7.0 kernel, so it won’t directly fix 580.x. The script patches the DKMS source, rebuilds it, runs `dpkg --configure -a`, and updates initramfs.

Basically:

Code:

git clone https://github.com/egeekial/nvidia-550xx-dkms-proxmox.git
cd nvidia-550xx-dkms-proxmox
bash apply-patches-proxmox.sh

Not a general NVIDIA fix, but it got the Debian 550 package building again for me. I just upgraded to the latest Proxmox kernel (7.0.2-3-pve), and DKMS successfully rebuilt the driver automatically.

Thanks!

But driver 550.x which is available via debian repo is too far outdated for me.

But maybe some parts of the patches are helpful, I'll take a look, appreciate the link!

Has anyone got any idea for my seeminly hopeless situation with nvidia drivers on the proxmox host?
Hardware: GTX 1060 (Pascal) + GTX 180 Ti (Kepler)
PVE version: 9.1.2
The problem: Nvidia Driver 580.x is the last series supporting Pascal/Kepler hardware.
It builds fine on kernel 6.17 but since proxmox updated to kernel 7.0 it fails due to VMA locking API changes (VMA_LOCK_OFFSET removed, __is_vma_write_locked signature changed in mmap_lock.h).
The repositorys

The debian12 CUDA repo has 580.x but is signed with a SHA1-bound key, which trixie's sqv rejects since Feb 2026

The debian13 CUDA repo has working signing but no 580.x, only newer driver series that dropped Pascal/Kepler support

The debian 13 repo has only driver 550 which is too far outdated and I had issues with it

What I think to do:
Pin the kernel to 6.17.13-7-pve and held kernel 7.0 packages, but due to exploits, I don't really wanna do that?
Also what would be the suggested way to do this?

Is there a patched 580.x build anywhere that supports kernel 7.0's new VMA API?

Is there a plan for the debian13 CUDA repo to carry 580.x for legacy hardware?

Any other suggested approach for Pascal/Kepler on PVE trixie long-term?

6.17 is patched for that recent exploit, get the -8 version from repo.

Last edited: May 16, 2026

just use nvidia v580.157.01 - dkms compiles with no issues so far on pve-kernel-7.0+

Same GPU here (GTX 1060, Pascal), so I've been watching this thread.

Still on PVE 8.4 at home, haven't moved to 9 yet. The 1060 drives Immich and
Jellyfin (CUDA for ML, NVENC/NVDEC for transcoding), driver 580.159.04 on DKMS.
There's irreplaceable family data on this box, so a kernel switch that bricks
the boot if DKMS fails mid-upgrade is exactly what I'm not willing to risk.

I'll be honest, the pin-6.17 + hold-7.0 approach doesn't appeal to me as a
destination. 6.17 is interim-based and won't be patched forever, so it's just
kicking the can. What I want before upgrading is 580 building on the actual
current kernel.

Which is why @kanemari's #7 is the post I care about: 580.157.01 building on
7.0+ with no issues. If that holds up it changes everything for the Pascal
crowd. Two things I'd love confirmed before I trust my setup to it:

Anyone tested 580.159.04 specifically on 7.0? It's newer than .157.01 so I'd assume the VMA fix is in, but assuming isn't testing.
Proprietary or open module in that build? Pascal has to run the proprietary one, so that detail decides whether this helps us or not.

Every earlier failure here was an older 580.x (580.105 / .95 / .82) against the
VMA locking change, so the newer builds may well have caught up. Worth pinning
down exactly which versions are safe.

推荐订阅源

Proxmox Support Forum