Double Debian update: 11.11 and 12.7 arrive at once The latest update to Debian "Bookworm" arrives at the same time as the last ever update to "Bullseye," and there's trouble ahead for Nvidia legacy users. The end of August saw two new point upgrades for Debian fans. The project published updates for two separate releases: one for Bookworm in the form of Debian 12.7, and, on …
Debian taking a lesson from Apple ...
Nope ...
It is not a Debian thing.
The problem originates within the greedy assholes at Nvidia.
Nvidia drops support for older/unsupported end-of-lifed cards all the time.
And along with that support go the Linux drivers/firmware.
The alternative these days is to use the nouveau drivers which are getting better as time goes by.
I won't ever purchase/use any Nvidia product again.
.
But the latest devuan has a legacy Nvidia package. Allowed my older card to work fine after upgrading. Wasn't super smooth to figure out as this is the only time I've run into compatibility issues with a kernel since I started using Nvidia back in 1999.(I tend to be very conservative in my configs, am aware of lots of issues if I ran more current kernels over the years).
Since devuan is based on debian I assume it's the same there too
https://packages.debian.org/bookworm/nvidia-legacy-check
now that I'm back home could poke at my system for more info, seems this is the legacy driver
https://packages.debian.org/bookworm/nvidia-tesla-470-driver
" This version only supports GeForce, NVS, Quadro, RTX, Tesla, ... GPUs based on the Kepler, Maxwell, Pascal, Volta, Turing, Ampere, or newer architectures. The (Tesla) 470 drivers are the last driver series supporting GPUs based on the Kepler architecture. Look at the legacy driver packages for older cards. "
The server that I use this on has a "NVIDIA GeForce GT 720" GPU (fanless). Except for laptops that have fans, the only Nvidia GPUs I've ever used have been fan less, with the first being a whitebox TNT 2 that I recall purchasing at Fry's electronics in 1999.
The video card in my DVR is a GT 610, an Nvidia Fermi-chipset model, and the 390 driver is the last in the Devuan package archive to support it. Someone in the maintenance pipeline has been nursing it along; version 390.157-8 compiles and links with the 6.10 kernel series.
This card's stock fan is loud, so I rewired it to run on 5V. I don't drive the GPU hard enough to need the fan to run faster than it does on 5V.
Every time there's an update to this driver package, I make sure to download all the associated .deb files, in case they disappear from the repos.
For those with older laptops and built-in nvidia hardware using the nvidia 390 drivers or newer, or for desktops as well, drivers can be patched and built to restore full graphics driver functionality. Yes, it is a "patch-scramble" for each new minor version change of the Linux kernel, but the drivers are patched and happy through Linux 6.10.8.
The only catch -- many times, unless your distro provides a community supported package that does the work to patch and update -- that may be up to you, e.g. https://aur.archlinux.org/packages/nvidia-390xx-utils. Tis the Linux way - choice - and the choice sometimes ends up in your lap.
Fortunately for more experienced users, the linux kernel is fairly divorced from the distro. You can run older kernels on newer distros without much of an issue in most cases. With debian/dpkg it's easy to flag a package to "hold" so you don't get the new kernel. On my previous laptop I held my kernel for probably 3 years as I got tired of every 2nd or 3rd kernel update breaking the sound on the laptop in some way.
So worst case, you can probably run the 6.8 or whatever is being shipped now probably for the next 5+ years if you REALLY wanted to and continue to update your distro in other ways and keep your old Nvidia card running(assuming you care about using the proprietary drivers). Of course if there is some super critical security thing that comes out then you may want to consider that, but for most people, the only such situations I'd be concerned with is with remote exploits (such as bugs related to handling malformed network packets which could lead to a crash etc which are super rare).
One of the unexpected benefits of me switching to NixOS is that even kernel patching is declarative.
My motherboard wants a version of the it87 driver that exposes more ports than the kernel bundled driver allows; I forgot the details but the solution was to have a custom built it87 driver and disable the kernel-supplied one.
Both driver build and kernel change are relatively simple to express in some Nix code, which I added to that machine's NixOS configuration, and since then - well over a year now, three NixOS releases and numerous kernel version bumps - that code just does the right thing. If a Nix upgrade comes.with a new kernel, it gets patched, the custom it87 driver gets built, and all I ever notice is spinning fans while the kernel compile happens.
It's magic, frankly. I've been using Linux since pretty much day one and this is the first time that something like this actually works.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
