Nvidia 390.25 from fedora-multimedia repo boot locks my machine

So, I’m originally on 384.111 just fine, then fedora-multimedia decided it’s new CUDA base was 390.25… This broke OBS FFmpeg and NVENC so I can’t stream or record anymore…

I said, fine… I’ll upgrade to the repo recommended 390.25 from the repo itself… after it installs… it boot locks my machine, printing 240 invisible errors per second, flooding a system log somewhere… It’s impossible to even get to another TTY terminal cause it’s flooding the system with so many errors. I can’t even type my login the kernel’s been flooded with so many errors. I tried restarting the machine in rescue mode, no dice.

Have I been screwed by fedora-multimedia? These were run on the compatible kernels for the drivers.

Wow, you seem to be having lot of problems lately.

Thank goodness this was on my secondary Fedora 27 passthrough installation cause I wouldn’t know what else to do if it was one of my primary installations. But now I know to blacklist the CUDA libraries in DNF cause 384.111 just works, while 390.25 I have no clue if they’ve changed the OpenGL version to 4.6, which breaks all old legacy OpenGL GLSL contexts cause it expects 4.5.

Edit: Oh, it gets better… Reports are 390.25 further freezes people’s systems in combination with the meltdown patches.

You know what, screw it. This is just something I’m going to receive no help for cause it’s impossible to fix. Wiping the drive my Passthrough FC27 OS image was on and just starting from scratch at another time. It will take another 8 hours to get back up and running again, even with a surviving qcow2 image.

Sorry to hear that man :frowning:

This is why people who get frustrated go to debian/ a more stable distro.

Yeah, but Fedora’s @virtualization DNF command is so good for packages. APT has nothing on that.

1 Like

390 was considered bugged on release because of the specter thing on asic’s I thought.

Seriously this has all gotten out of hand now. Roll back and wait for 391 methinks.

1 Like

Well, the repo can’t roll back cause it updates based on raw source and doesn’t provide older builds, so I just have to blacklist the packages in the repo and go with what’s already in the pre-packaged Nvidia driver in 384.111 for now.

There doesnt seem to be anyone else with this issue, is this a vm? have you made odd changes to your system?

CentOS in this case.

If it doesnt exist where are you getting this from?

There’s a possibly issue with the 390 driver and linux 4.14.16, which seems to not be an issue by just selecting 4.14.14 instead.

You can also just boot emergency mode and rebuilt the intiram if your using the negativo17 drivers.

Um, I’m using 4.14.11. And I’ve disabled Kernel updates cause I don’t want to mess things up further. Not fixing what ain’t broken.

I’m just going to prevent DNF from updating the Nvidia drivers with those broken repositories cause I’m using 384.111 from the .run compressed archive from Nvidia themselves. Also, too late to rebuild the initramdisk, I already wiped the drive. I couldn’t even get to a TTYS terminal it was flooded with that many kernel errors.

Linux Game Cast mentioned having all sorts of issues with some of the newer drivers, specifically the 390.25. Not that them complaining about trouble actually solves anything, but I figured I would mention that this isn’t an isolated case. It may just be that they need to fix the drivers.

https://linuxgamecast.com/2018/02/linuxgamecast-weekly-285-weeb-garbage/

maybe a dnf downgrade would have helped if you could get back into the system. Maybe getting a LiveUSB and using systemd-nspawn to boot the system and check logs or do whatever else you need to get it back up and going

Yeah, I couldn’t even boot into the system at all cause SDDM couldn’t even start.

Come to think of it, that might have been the issue. Is cause SDDM was Segfaulting to a point where it got stuck in an infinite segfault loop.

You can boot into single user mode or rescue mode. Just fyi for next time if you have issues with Linux in general.

I did try the rescue Kernel. Same issue with a segfault loop.

Not rescue kernel. Single user mode/emergency mode bypasses most things including loading drivers like nvivda. The only reason it wouldn’t work is if you had changed the kernel somehow

the issue is not exclusive to Fedora. I’ve been using CUDA repo for my OpenSUSE install and the 390 series driver causes hard locks of my system from time to time. Reverted back to older one and it seems to get back to normal. The bad news is that rolling back down to 384 is tricky as there seem to be a part missing for the current cuda to work.

WARNING: The 384.130 drivers also hard lock Fedora installations. DO NOT UPDATE if you managed to get 384.111 working on Fedora 27.

I managed to break the segfault loop by deleting xorg.conf. Xorg was trying to call up the Nvidia driver but it just somehow fails to do so on the newer drivers. DO NOT update.

Edit: Managed to recover this potentially screwed up installation by simply deleting that xorg.conf file and installing 384.111 again. If you get stuck in a segfault loop, delete xorg.conf with a live image.

Bump. The latest Fedora 28 kernel/systemd update to 4.17.7 also causes even the LATEST Vulkan driver 396.24.10 to boot lock again in this same way. Stay away from kernel updates for now AGAIN.

And once again, If you’re on a old 4.17 Fedora kernel and you’re testing DXVK on Fedora 28, the new 396.54.05 drivers break the 4.17 kernels. Stick to 396.54.02 if you need DXVK or Vulkan on Fedora 28.