260

Rant about Nvidia related updates on Linux (media.kbin.social)

submitted 1 year ago* (last edited 1 year ago) by thingsiplay@kbin.social to c/linux@lemmy.ml

105 comments fedilink hide all child comments

There are many reasons to dislike Nvidia on Linux. Here is a little thing that bugs me all the time, the updates. Normally the system updates would be quick and fast, but with the proprietary drivers of Nvidia involved, it gets quiet slow process. And I am not even talking about any other problem I encounter, just about the updates.

As an Archlinux based system user (EndeavourOS to be precise), I get new Kernel updates all the time. That means every time a new Kernel version is installed, the Nvidia driver DKMS has to be installed too. And that is basically the slowest part. But that's not too bad, even though it's doing this twice for each Kernel I have once.

What's more infuriating is, if you also happen to use Flatpaks for a very few applications. I really don't have many Flatpaks at all. Yet, the Nvidia drivers are installed in 7 versions or what?! And they are full downloads, each 340 MB or more. This takes ages and is the only part that takes long to update Flatpak system. I always do flatpak remove --unused to make sure nothing useless is present. /RANT (EDIT: Just typos corrected.)

top 50 comments

sorted by: hot top controversial new old

[-] nottheengineer@feddit.de 72 points 1 year ago

And in addition to that, it's the only thing that breaks on my system that isn't my fault.

My next GPU will definitely be AMD unless Intel catches up very quickly.

[-] SHITPOSTING_ACCOUNT@feddit.de 4 points 1 year ago

My embedded AMD GPU has been unusable under Ubuntu. Constant crashes/freezes. When trying to find a workaround (unsuccessfully), I found lots of other people with slight variations of the same problem - same symptoms, but different root causes... seems like at any time there are several system-breaking bugs and every time one is removed another is introduced. You just have to hope your kernel happens to be one that happens to work with your specific config.

My next platform will be Intel-based.

[-] Nanabaz2@lemmy.world 8 points 1 year ago

Which embeded gpu?

[-] Molecular0079@lemmy.world 5 points 1 year ago

I don't get why people bringing up AMD issues always get down voted. The bias is real. I too am getting constant freezes with my Radeon 680M that have gone unresolved for almost a year.

Quite a few people are experiencing this so it isn't an isolated issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2220

[-] michaelrose@lemmy.ml 4 points 1 year ago

A few reasons. It's received wisdom that AMD are the good guys because in the Intel / AMD slog they are the underdogs fighting the good fight and bringing good affordable products to all vs intel who has historically behaved in a sleazy underhanded and anti-competitive fashion and when they bought ATi they moved ATi from a maker of shitty proprietary poorly supported pieces of shit to an open source friendly maker of acceptable GPUS.

Since Nvidia is the bad guy in that fight it would be handy if Nvidia was also badly supported buggy, inferior. The fact that Nvidia is actually more stable, well supported, and generally better is somewhat a fly in the ointment.

It's especially humorous when its coming from users of a permanent beta distro like arch where the kernel update process is that the new kernel is pushed extremely quickly after release. Expert arch users realize that means they are their own QA as far as out of tree modules. Actually stable distros express what is known to work as dependencies such that you trivially get something that is known to work when you press go. They also don't run the kernel release that was cut this morning.

Meanwhile users of arch derived distros, who may or may not claim to be running arch while believing their distro is ubuntu with faster updates yell that nvidia is broken when 6.3 doesn't work the day it was cut with nvidia using a driver that doesn't claim to support 6.3. The fact that this dependency is known but not encoded into arch packages isn't an Nvidia problem.

Even Manjaro a distro run by folks who once told their users to set their clocks back because they forgot to renew their SSL Cert figured out they can avoid almost as much trouble as smart people can avoid by actually reading by just being lazy and not pulling changes instantly.

load more comments (2 replies)

[-] jlh@lemmy.jlh.name 4 points 1 year ago

AMD works fine for me. I had a Thinkpad P14s for a while and my gaming computer uses a 6800 XT.

load more comments (1 replies)

load more comments (6 replies)

[-] Blackmist@feddit.uk 3 points 1 year ago

I would have thought Intel would be decent on Linux. It falls behind on Windows because it doesn't have all the years of broken game fixes baked into the drivers like AMD and nVidia have, but isn't all the Linux gaming done through Vulkan wrappers around DirectX?

[-] ozymandias117@lemmy.world 7 points 1 year ago

Intel has the best software support - AMD just has more powerful hardware and good enough software support

nvidia has the best hardware on paper, but no software support

A large number of games support Linux natively thanks to Valve’s pushes, and use OpenGL

DXVK (directx to vulkan) is one of the more popular translation layers for other games

Intel also uses DXVK on Windows to help with older versions of DirectX (primarily DX9 afaik) on their ARC cards

[-] 30p87@feddit.de 3 points 1 year ago

Hyped for the RX 7700/7800 XT, cuz they either replace my previous goal of a 4k capable card or bring down prices for the 6900/6950 XT a bit.

load more comments (1 replies)

[-] qwesx@kbin.social 39 points 1 year ago

That means every time a new Kernel version is installed, the Nvidia driver DKMS has to be installed too. And that is basically the slowest part.

ZFS users: "First time?"

[-] thingsiplay@kbin.social 14 points 1 year ago

@qwesx I am not familiar with ZFS filesystem. How does it affect this or plays a role?

[-] Molecular0079@lemmy.world 25 points 1 year ago

ZFS also requires a lengthy DKMS build step to compile a kernel module.

[+] skullgiver@popplesburger.hilciferous.nl 26 points 1 year ago* (last edited 11 months ago)

[deleted]

[-] thingsiplay@kbin.social 12 points 1 year ago

@skullgiver

I doubt they’re all full downloads. Flatpak does a lot of deduplication.

It downloads every single of them fully. Took 15 minute or so for all the packages or longer. This is going on since I started with Flatpak. The Nvidia drivers are not de-duplicated or partial downloads on my system.

You can see it in your screenshot as well, >140MB downloads that are marked as completed even though only a few megabytes were actually fetched.

That's not the one I am complaining. The drivers are the ones named as org.freedesktop.Platform.GL32.nvidia-xxx-xx-xx . These are the different driver versions of Nvidia and each of the 7 versions are 340 MB or more and are always downloaded fully. You can see each of them like 340,9 / 341,8 MB. What you was referring to is not what I am complaining. The extraction of the archives and installation is quick. Every other package is quick, only those take this long.

but the sheer download size isn’t the problem in my experience. Not great, but not as terrible as it may seem.

It isn't a hard problem, but very annoying. Not sure how fast internet access you have, I have under 7 MB/s. And only counting the Nvidida drivers through Flatpak alone is 2.3 GBytes. Imagine adding all the other updates in Flatpak, plus the system update of my OS itself and the DKMS. It adds up a lot.

[-] urbeker@lemmy.world 8 points 1 year ago

I suffered from this a few months ago as well. The space and bandwidth flatpak was taking for about 2 small cli applications was obscene. Like 30gb all because it had accumulated about 10 nvidia drivers. I found the issue on github and it was closed as intended behavior. I install alot of rust apps from source and updating them from source was faster and easier than updating flatpak just due to the overhead of maintain those drivers.

That and the fact that every app has to be run through an alias or a. overly verbose command made me discount flatpak as a serious project. You can't ignore UX to that extent and just rely on technical merits.

[-] elouboub@kbin.social 21 points 1 year ago

Uses NVIDIA

Imaaaagine!

Seriously though, I feel for you. NVIDIA is shit and while you're dealing with this, I hope you know which vendor you'll not be giving money to in the future. Fuck NVIDIA.

[-] thingsiplay@kbin.social 10 points 1 year ago

@elouboub It's AMD. 100% sure. And the best part is, the situation with Nvidia is nowadays improved. So this is the current best case we have...

load more comments (2 replies)

[-] EccTM@lemmy.ml 19 points 1 year ago

The flatpak thing is a known issue, where it doesn't correctly remove the 32bit package on update.

This bash script should find the latest and remove the rest:

#!/bin/bash
# Filename: flatpak-clean-nvidia.sh

# List latest 64bit Nvidia flatpak (it doesn't leave cruft behind) and note the version
FLATPAK_LATEST_NVIDIA=$(flatpak list | grep "GL.nvidia" | cut -f2 | cut -d '.' -f5)

# List all installed 32bit Nvidia flatpaks, ignore latest version, uninstall rest of list
flatpak list | grep org.freedesktop.Platform.GL32.nvidia- | cut -f2 | grep -v "$FLATPAK_LATEST_NVIDIA" | xargs -o flatpak uninstall

[-] ProtonBadger@kbin.social 12 points 1 year ago* (last edited 1 year ago)

I have an alias I call "upd" that runs "yay ; flatpak update", I just run that, press Y at the first prompts and then let it run in the background while I do other work. It really doesn't matter at all how long it takes. I do have NVidia but generally I don't feel it takes very long as we don't get new kernels every day. You could use the linux-lts kernel for much more rare kernel updates.

It's a bit like bittorrents, I don't need them to download in 30sec, I start it and return to check on it whenever I think of it.

I have changed my opinion on flatpak btw, I really like that the apps are not spread all over my system but instead sandboxed neatly, have fewer dependency versioning issues and it's really easy to use.

[-] thingsiplay@kbin.social 5 points 1 year ago

@ProtonBadger The entire update process takes 20 minutes or so (never timed it), at least sometimes. I also had an alias before, but recently rewrote it as a script to do similar things, including pacman, yay, flatpak, rustup and a few other things. And from all of this stuff, most of the time its flatpak that inflates the update process time.

[-] ProtonBadger@kbin.social 3 points 1 year ago* (last edited 1 year ago)

That's abnormal, it shouldn't be like that. My flatpak rarely has updates (compared to Arch/yay) and they're quite fast, still less than half a minute even if there's updates to the NV libs (I didn't time it). There must be some kind of particular issue? What's your setup?

Looking at it - I got flatseal, chrome, firefox, thunderbird, dropbox, steam, joplin, cryptomator, mesa, NV libs, gimp, discord, resynthesizer, libreoffice and some other bits on flatpak. It's on an SSD, Internet 150Mbps. Is it installation or download that's slow for you? With it being 20min I would guess there's a problem with the download speed from the server, routing issue to flathub, etc? Flatpak is not that much of a slog.

load more comments (1 replies)

[-] miss_brainfart@lemmy.ml 11 points 1 year ago

What other problems do you encounter? Updates are a bit annoying, but I haven't had any actual issues so far.

[-] thingsiplay@kbin.social 7 points 1 year ago

@miss_brainfart There are many little things encountered over the years. But I do not have a list or anything like that. Nvidia is always in my way somehow. Wayland support was or still is not great with Nvidia in example and one of the reasons why I don't consider trying Wayland.

Then for a long time it G-Sync didn't work properly with applications that should, had some tearing too related to problems with picom. I have to run the nvidia-settings gui once at boot, otherwise I have all the problems described before. I use a command to run it without showing gui. Found this solution by accident after 6 months of terror, as searching the web didn't help me.

And for a long time, I got used to it and it wasn't driving me crazy or anything. When I put my system to sleep and wake it up, the Firefox window would have garbage pixelation (complete random). I just had to move the window once and everything was normal again. That's because it has GPU acceleration and somehow this is a known bug by Nvidia that is unsolved. Or at least it was, because this does not happen anymore.

What do we have else in my head right now? Gamescope, the SteamOS compositor, didn't work with Nvidia before it got official support. I needed that to solve a problem, to play a certain game that was otherwise not playable. So yes, that's not a problem anymore I think (didn't use it for a while now), but it was another thing that was in my way. I know this has todo with the official support of Gamescope and not just being nvidia, but it was related to Nvidia and in my way.

Somehow... the problems I encounter are connected to Nvidia. But as said, I don't have a full list of problems and these are just a few things come to my mind.

[-] miss_brainfart@lemmy.ml 3 points 1 year ago

Yeah okay, I don't even use a DE that supports Wayland, and I don't have a need for it anyway, since both my monitors run at the same fixed refresh rate.

Now that you say it, windows being all garbled and pixelated after waking up from sleep is definitely something I encounter quite often.
Annoying, but nothing that breaks everything, so that's good I guess.

Other than that though, my experience is flawless.

I'm still going to move to AMD though.

[-] ithas@artemis.camp 4 points 1 year ago

The latest drivers on mint, 535, cause flickering on my monitors. There are a bunch of posts about this; when I installed them when they came out my screens went black and never recovered, had to power off manually, and then the top part of my monitors would just flicker every 15-30 seconds. I rolled back to 525, and now that it had been a couple months I had just tried to upgrade again recently but the problem remains, black screen, reboot, flickering.

[-] miss_brainfart@lemmy.ml 3 points 1 year ago

I used Mint briefly on my desktop PC, and the Nvidia driver was the one thing that gave me issues. The recommended one was too old for some of the things I wanted to do, but the most recent one at the time made everything unstable.

Now I use EndeavourOS, and Arch seems to handle that driver a lot better.

[-] russjr08@outpost.zeuslink.net 2 points 1 year ago

The screen flickering issue is also sadly not limited to Mint. I was on Fedora over the last few months, and am now on Arch and still get that issue.

Also doesn't seem to be restricted to the DE either, just the driver itself being shitty it appears.

[-] Molecular0079@lemmy.world 2 points 1 year ago

Haven't had many issues either. My Nvidia 3090 has given me way less trouble than both my Vega 64 and Radeon 680M.

[-] worsedoughnut@lemdro.id 9 points 1 year ago

My exact solution to this on Endeavour was to just stop using flatpaks lol.

Literally everything I used from flathub was also either on the AUR or trivial to install manually from the host GitHub.

[-] 1984@lemmy.today 8 points 1 year ago

I was wondering what the fuss was about until I read flatpak. I don't use those, no reason to on Arch since everything is in the AUR. But it was interesting to read.

[-] thingsiplay@kbin.social 12 points 1 year ago

@1984 Unfortunately not everything is in the AUR or I do not want to trust everyone on the AUR. And there are other reasons to use Flatpak over native packaging (including AUR):

kdenlive and Krita: I do not want to install the entire suite and dependencies of KDE.
bottles: The Flatpak version is the recommended one by the devs and the only supported one I think.
xemu: Yes it's also available on, but I do not know who the uploader and manager of this binary is. While the Flatpak version an official package is.
zeal: Same reason as xemu.

And that's basically it (ok there is Flatseal too... but that does not count to our discussion). Everything else is installed through native packaging. So there is not much reason to use Flatpak and I just started with it recently. But there are sometimes reasons for.

load more comments (16 replies)

[-] michaelrose@lemmy.ml 7 points 1 year ago

You have a bunch of duplicated stuff because flatpak is a piece of shit. With traditional packaging apps supporting your platform would get exactly one choice. Support the fucking version of nvidia that everyone else gets to or fuck off. In all likelihood all your shit would work work with the most recent release but because they have the option to be lazy fucks and make you download Nvidia 7 times this is your life now. Also if dkms takes appreciable time you either need to stop running Linux on a toaster or delete some of the 17 kernels you are hoarding for some reason. You need like 2 the one that you know works and the new one you just installed.

[-] OsrsNeedsF2P@lemmy.ml 12 points 1 year ago

As an app developer, we provide the source, binaries, and a Flatpak, but we sure as hell aren't going to help you debug the Nvidia drivers on some random distro if you don't pick Flatpak.

load more comments (2 replies)

[-] harrim4n@feddit.de 4 points 1 year ago

[-] thingsiplay@kbin.social 3 points 1 year ago

@michaelrose Thank you for your help. Much appreciated.

load more comments (3 replies)

[-] hitagi@ani.social 5 points 1 year ago

I've kind of gotten used to the first issue already. I don't know if I can switch to the non-DKMS drivers now that I'm using the LTS kernel though.

[-] aleph@lemm.ee 4 points 1 year ago

Which terminal font is that, by the way?

[-] thingsiplay@kbin.social 5 points 1 year ago

@aleph "Cascadia Code"
Here is fastfetch output:

OS: EndeavourOS x86_64
Kernel: 6.1.51-1-lts
Uptime: 50 mins
Packages: 1149 (pacman), 34 (flatpak)
Shell: bash 5.1.16
Display (AG271QG): 2560x1440 @ 120Hz
DE: qtile
WM: Qtile 0.22.1 (X11)
Theme: Arc-Dark [GTK2/3]
Icons: Qogir-dark [GTK2/3]
Font: Cascadia Code (12pt) [GTK2/3]
Cursor: Qogir
Terminal: xfce4-terminal 1.1.0
Terminal Font: Cascadia Code (13pt)
CPU: Intel(R) Xeon(R) E3-1230 v3 (8) @ 3,7 GHz
GPU: NVIDIA GeForce GTX 1070
Memory: 3,11 GiB / 15,57 GiB (20%)
Disk (/): 122,70 GiB / 227,21 GiB (54%) - ext4
Disk (/media/Backup): 149,83 GiB / 916,70 GiB (16%) - ext4
Disk (/media/Emulation): 3,83 TiB / 5,41 TiB (71%) - ext4
Disk (/media/My): 1,04 TiB / 3,58 TiB (29%) - ext4
Disk (/media/System): 411,39 GiB / 915,82 GiB (45%) - ext4
Locale: en_US.UTF-8

load more comments (5 replies)

[-] a2r@feddit.de 3 points 1 year ago

Looks like Cascadia Code to me

[-] Sina@beehaw.org 4 points 1 year ago

If you use the Zen kernel there is no reason to keep the regular one around.

[-] MalReynolds@slrpnk.net 6 points 1 year ago

I always did, saved my ass a couple of times when Zen broke.

load more comments (1 replies)

[-] gataloca@lemmy.world 3 points 1 year ago

If you have several kernels you might want to disable the fallback kernels. You do so in the .preset files in /etc/mkinitcpio.d/

But yeah this is the downside of using flatpaks. That's why I think it's better to avoid flatpaks and other similar sandbox environments. I know the Linux community are desperate for the increased stability and supposed benefits to security but you're paying the price in worse performance and high disk usage.

[-] radioactiveradio@lemm.ee 2 points 1 year ago

Eyyy, i just updated all that too!

load more comments

this post was submitted on 04 Sep 2023

260 points (97.4% liked)

Linux

48099 readers

759 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

nooter692@lemmy.ml

AgreeableLandscape@lemmy.ml

MarcellusDrum@lemmy.ml

cypherpunks@lemmy.ml

cyclohexane@lemmy.ml

d3Xt3r@lemmy.nz