A question about Nvidia dkms drivers from the AUR

Kresimir · July 25, 2020, 5:25pm

Hello!

Earlier today, I installed EndeavourOS on one of my desktops. In general, I am very, very happy with the OS. Performance is excellent, KDE Plasma works flawlessly, there is absolutely no bloat, user friendly tools and scripts are great! EndeavourOS will most likely replace all my Manjaro computers within the next month or so. The devs did a fantastic job with this distro. 10/10

Since I’m sill quite a newbie, there is one thing that slightly confuses me. This old computer has a fairly ancient Nvidia GeForce GTX 550 Ti graphics card:

Here is the output of `inxi -Fxxxa`

System:    Kernel: 5.7.10-arch1-1 x86_64 bits: 64 compiler: gcc v: 10.1.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=500a40b3-c412-4944-8f1d-9d6aee8a0a4b rw amd_iommu=on iommu=pt 
           loglevel=3 nowatchdog 
           Desktop: KDE Plasma 5.19.3 tk: Qt 5.15.0 wm: kwin_x11 dm: SDDM Distro: EndeavourOS 
Machine:   Type: Desktop System: Gigabyte product: N/A v: N/A serial: <superuser/root required> Chassis: type: 3 
           serial: <superuser/root required> 
           Mobo: Gigabyte model: 990XA-UD3 v: x.x serial: <superuser/root required> UEFI: American Megatrends v: FD 
           date: 02/04/2013 
CPU:       Topology: 6-Core model: AMD Phenom II X6 1090T bits: 64 type: MCP arch: K10 family: 10 (16) model-id: A (10) 
           stepping: N/A microcode: 10000DC L2 cache: 3072 KiB 
           flags: lm nx pae sse sse2 sse3 sse4a svm bogomips: 38594 
           Speed: 1643 MHz min/max: N/A Core speeds (MHz): 1: 1643 2: 1630 3: 1533 4: 1594 5: 1766 6: 1234 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass status: Not affected 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full AMD retpoline, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA GF116 [GeForce GTX 550 Ti] vendor: CardExpert driver: nvidia v: 390.138 bus ID: 01:00.0 
           chip ID: 10de:1244 
           Display: x11 server: X.Org 1.20.8 compositor: kwin_x11 driver: nvidia unloaded: fbdev,modesetting,vesa 
           alternate: nouveau,nv display ID: :0 screens: 1 
           Screen-1: 0 s-res: 2560x1440 s-dpi: 108 s-size: 602x342mm (23.7x13.5") s-diag: 692mm (27.3") 
           Monitor-1: DVI-I-1 res: 2560x1440 hz: 60 dpi: 109 size: 597x336mm (23.5x13.2") diag: 685mm (27") 
           Message: Unable to show advanced data. Required tool glxinfo missing. 
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] SBx00 Azalia vendor: Gigabyte driver: snd_hda_intel v: kernel 
           bus ID: 00:14.2 chip ID: 1002:4383 
           Device-2: NVIDIA GF116 High Definition Audio vendor: CardExpert driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           chip ID: 10de:0bee 
           Sound Server: ALSA v: k5.7.10-arch1-1 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte driver: r8168 v: 8.048.03-NAPI 
           port: d000 bus ID: 03:00.0 chip ID: 10ec:8168 
           IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: 94:de:80:c7:ff:fe 
Drives:    Local Storage: total: 931.51 GiB used: 21.44 GiB (2.3%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda vendor: Western Digital model: WD1003FZEX-00K3CA0 size: 931.51 GiB block size: physical: 4096 B 
           logical: 512 B speed: 6.0 Gb/s rotation: 7200 rpm serial: WD-WCC6Y4SCHS31 rev: 1A01 scheme: GPT 
Partition: ID-1: / raw size: 931.39 GiB size: 915.77 GiB (98.32%) used: 21.44 GiB (2.3%) fs: ext4 dev: /dev/sda2 
Swap:      Kernel: swappiness: 60 (default) cache pressure: 100 (default) 
           ID-1: swap-1 type: file size: 5.00 GiB used: 0 KiB (0.0%) priority: -2 file: /swapfile 
Sensors:   System Temperatures: cpu: 33.1 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 184 Uptime: 2h 55m Memory: 15.61 GiB used: 2.80 GiB (17.9%) Init: systemd v: 245 Compilers: gcc: 10.1.0 
           Packages: pacman: 989 lib: 213 Shell: Bash v: 5.0.17 running in: konsole inxi: 3.1.04

By default only the nouveau driver was installed (and this caused KDE Plasma to freeze after a few minutes and constantly require reboots). The appropriate proprietary driver for this card is 390xx. The wiki page has some confusing info about this driver: in one place it says it’s newly moved to legacy, but further down it says: “nvidia-installer only supports the latest driver and nvidia-390xx”. Does this apply to nvidia-installer-dkms, as well?

Well, I tried it and nvidia-installer-dkms detected my card and installed the 450.57 driver which of course, made my system unbootable. Not a big problem, I made a Timeshift snapshot just in case so I booted from a live image, chrooted and restored it.

Then, I installed nvidia-390xx-dkms from the AUR. This works flawlessly, everything runs smoothly, KDE does not freeze any more.

But I wonder, what will happen when kernels update? Do I have to do something about these drivers when that happens? Is there a way to configure it so that I can only update with pacman -Syu and forget about graphics drivers?

dalto · July 25, 2020, 5:27pm

dkms modules get removed and re-built when kernels are updated. In theory everything should just work, that is the nice thing about dkms modules, they aren’t tied to a specific kernel version.

Kresimir · July 25, 2020, 5:29pm

Excellent! I figured as much, but I wanted to avoid a nasty surprise on the next update.

Thank you!

manuel · July 25, 2020, 5:33pm

As 390xx drivers moved to AUR recently, we removed 390xx support from the nvidia-installer-dkms.
As a workaround what you did (install 390xx-dkms manually) should however work.

By the way, did nvidia-installer-dkms in any way warn about not detecting your nvidia card?

Kresimir · July 25, 2020, 5:36pm

No, no warning at all. In fact, quite the contrary, it detected my card correctly and then installed the wrong driver.

I think the wiki page should be edited to make it clear that 390xx support was removed from nvidia-installer-dkms.

manuel · July 25, 2020, 5:38pm

Yes, the wiki needs to be changed now.

Could you show the output of command

  lspci -vnn | grep -P 'VGA|Display'

so I can make sure why it was detected falsely?

dalto · July 25, 2020, 5:47pm

@Kresimir is over his daily reply limit for a new user so he asked me to post this on his behalf:

Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64, NUMA node 0, IOMMU group 12
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] [10de:1244] (rev a1) (prog-if 00 [VGA controller])

manuel · July 25, 2020, 7:25pm

Thanks @Kresimir and @dalto !

As we cannot test all nvidia cards, the info you provided revealed a (fortunately a small one) bug in our nvidia database manager. I just fixed it and released a new nvidia-installer-dkms, version 3.3.4-1.

That version should now see that your card is not in our database, and it should also suggest installing nvidia-390xx-dkms from the AUR.

It would be great if you can verify it works on your machine by showing the output of these commands:

  nvidia-installer-update-db   # updates the card database only
  nvidia-installer-dkms -t     # test mode, does not modify your packages

Bryanpwo · July 25, 2020, 7:27pm

@Kresimir There’s a little warning for the 390xx and the 340xx drivers, when there’s a new kernel release, so I’m not talking about kernel point releases, but a new major kernel release. (5.7 to 5.8) Just wait with updating the kernel.
These drivers aren’t supported by Nvidia anymore, but by the community (Read Manjaro) the update for these drivers are usually released AFTER the new kernel is released.

Kresimir · July 26, 2020, 5:38am

Sorry for the slow reply, I’ve run out of replies on Discourse.

Thanks for the warning, Bryan! So, I probably should expect a nasty surprise in one of the next updates. I’ll keep the LTS kernel installed, just in case I can’t boot, hopefully there won’t be a major kernel release update both to linux and linux-lts at the same time.

Bryanpwo · July 26, 2020, 5:45am

Keeping LTS installed is a wise thing to do, in this case. The drivers usually will be updated within a couple of days, but most of the time the next day.

When there’s nothing crazy going on in my life I normally inform you guys over here when a major kernel release is coming.

ringo · July 27, 2020, 7:25am

Also keep Xorg update in sight…if there is a new Xorg. You need to find information that the ABI of nvidia can handle new xorg-server thats importand. mayby they put it later on who knows but with video drivers need the Xorg-server in a eye on the fly.

keybreak · July 27, 2020, 7:36am

Interesting discussion here!

@Bryanpwo
Why not store compatibility drivers in repo as well?
I think it was wise decision on Manjaro’s part to do so, drivers should belong in repo

AUR for drivers of any kind feels a little…well, you know, AURy
And by that i mean my paranoid thinking: “Well at least in repo it must have been somewhat checked!”

Personally when i install anything from AUR - i start to monitor source and build, diff changes etc…
Which would be real pain for cases like Nvidia drivers

That is good to know

Jeez, a lot to keep in mind

Kresimir · July 27, 2020, 7:41am

I think that’s up to the upstream (Arch) to decide. I don’t know why they dropped it, probably it was a lot of work to maintain it.

Hmm… This looks like a potential pita. There’s no xorg-lts I can have as a fallback, so if I have to update, I’m screwed. Thankfully, xorg rarely updates, but still… Thanks for the warning, none of this would have occurred to me until it was too late!

Bryanpwo · July 27, 2020, 8:26am

We follow Arch when it comes to the main decisions in the main Arch repo. Nvidia dropped those drivers and the reason why we don’t put it in our own repo has got to do with a decision we made more than a year ago while creating this distro.

As you might know, we started this distro to give a part of the Antergos community a new home. When Endeavour was still an idea on paper, we already had around 500 voices to take in considation in the development of the distro and the forum.

Back then the team was counting four guys with no experience in creating a distro and as former Antergos mods we didn’t want to make the same mistake, that ultimately became Antergos’ Achilles heel, the extended Antergos repo.

There were so many packages in that repo, it became very hard for the Antergos team to keep it up to date and eventually the out of date packages, together with some core packages, were causing major issues in the daily usage of the distro.

To avoid that, we’ve decided to keep the EndeavourOS repo small and clean, so no major and essential AUR packages in our own repo. We all have jobs and regular lifes next to this project and we don’t have always time to look into every single AUR package that would be in our repo at the time an update causes issues.

This is why we also don’t ship Pamac out of the box, on Antergos you had to cross your fingers when a Pamac update arrived, it either kept working or it completely broke. This decision didn’t go without a fight when we told the Antergos community about it, so as an alternative solution, we ship yay by default. Although we do have a mod who mantains pamac-git, we still stay with our original principle.

After install, this distro is all about customizing a system to your needs and you need to create some elbow grease along the way. The difference between this forum and the Mother based forum, is that the community is more than wiling to help you along the way and even if you have questions about Flatpack, Snaps or Google products, no one will judge you for using them.

Don’t mistake the lack of certain packages in our distro with the infamous RTFM attitude somewhere else, it is just a way to maintain this distro with a small team for years to come with genuine friendly help.

The name of this distro wasn’t picked because it just sounds cool, it is an Endeavour in the beginning, but you’re not alone…

Kresimir · July 27, 2020, 8:40am

As I’ve said a few times before, you fellows are doing an excellent job with this distro and the forum. I think it was a very wise decision not to bite more than you can chew and stick to mostly vanilla Arch, even if that sometimes inconveniences your average user, it’s nothing of an inconvenience compared to a poorly maintaned repo, so I compliment you on your smart decision.

I am a bit disappointed that Arch does not keep the legacy drivers in their repos, but what can you do… As long as I have a good workaround, I’m happy.

keybreak · July 27, 2020, 8:51am

No worries, when choosing between pure Arch and Endeavour in terms of community and ease of starting arch base - you win already

No no no…Are you telling me you’re not an universal AI merged into singularity?
I refuse to believe it!

~~Try to talk them out of it?~~
Doubt it would go very well…

I must say i’m really disappointed with this decision, although it’s understandable from purely technical / resource management standpoint…

Kresimir · July 27, 2020, 8:55am

What you can do is upvote this package on the AUR website:
https://aur.archlinux.org/pkgbase/nvidia-390xx/

If there are enough votes, it might get included back in the official repos. It’s a long shot, though, and I wouldn’t hold my breath (especially because they must have had a reason to remove it in the first place).

What you can also do is follow Torvalds’ example and give Nvidia the finger next time you’re shopping for a graphics card: https://www.youtube.com/watch?v=IVpOyKCNZYw (slightly NSFW).

keybreak · July 27, 2020, 9:14am

Done and done, maybe we should start company to bring it back and get more votes
But yeah…That’s very long shot at best.

From freedom standpoint - 100% best way to go!

But technically in my opinion, for serious professional use nothing still comes even near top segment of Nvidia products…
Plus sometimes i love to play games with GPU accelerated PhysX (yes on Wine you can get it to work too )
Dreaded proprietary crap, i bet it will be same with RTX now.))

For me it’s one of biggest love / hate relationship, in my times (8xxx / 5xx series) i’ve started some serious public companies against them for being absolute dishonest pieces of crap and selling exactly same hardware videocards locked only programmatically by drivers to behave worse and have less functionality.

Top GeForce compared to their Quadro bigger brothers i mean (so you could save yourself some serious thousands of $, if you was enough tech-savvy to mod their Windows drivers).

Well, it lead of course to some changes, now this bastards do exactly same as they did before with drivers, just with hardware chips / resistors (again, you still can mod them by just changing some small parts with your soldering skills), but otherwise they still essentially same videocards

So yeah, fully support Torvalds on that one, but still wait for better solution than currently available AMD / Intel for heavy-lifting stuff

Kresimir · July 27, 2020, 10:13am

This GTX 550 Ti was the last Nvidia card I ever bought (and it just came out when I bought it, so that was a long time ago, I still used windoze). It’s been all AMD for me since. Perhaps their high-end cards are not as great, but they work just fine, are much more affordable, and are not hostile to Linux.

I’m not much of a gamer anyway. I do use Blender from time to time, but I don’t do any heavy rendering.