MX Linux Forum

Posted: **Thu Jan 16, 2025 3:09 am**

I moved from a different distro because I liked the idea of a rolling release. Less work is good, but every time the new release rolls out it breaks Nvidia. The .5 release broke it again and I went through the hoops to fix it again but it breaks again. What I mean by breaking this time is after I fixed it all was fine then on a reboot the display parameters are mess up and I cannot select a different parameter. This time when I revert to nouveau driver it sticks to 3840x2160 and my old eyes (with glasses on) can't see that. Here I go again with a re-install. With a reinstall all goes fine until an Nvidia update and it all goes downhill from there. I am fine with a re-install and wish there was a version of MX that wasn't rolling for this reason. I will look to blacklist nividia and hop this solves my problem. I am not leaving MX, Love their work but this is just an Nvidia rant.

Posted: **Thu Jan 16, 2025 3:43 am**

MXMUX wrote: Thu Jan 16, 2025 3:09 am I am fine with a re-install and wish there was a version of MX that wasn't rolling for this reason.

MX Linux isn't a rolling release. Several people like to show up here and complain how much work it is to upgrade from one release of MX to the next. You might want to consider documenting the steps you take to repair your driver issues, and then pin that driver package so that newer versions aren't installed when you patch the machine.

Posted: **Thu Jan 16, 2025 4:02 am**

[/quote]
MX Linux isn't a rolling release.
[/quote]
How is it I go from 23 to 23.1, .2 .3 .4 5.? Only from the updates? I am not arguing I am asking.

Posted: **Thu Jan 16, 2025 4:23 am**

MXMUX wrote: Thu Jan 16, 2025 4:02 am How is it I go from 23 to 23.1, .2 .3 .4 5.? Only from the updates? I am not arguing I am asking.

Those are "minor version" updates that refresh the packages of the OS. If you installed MX-21 you automatically got the MX-21.1 updates when they were made available, and over time MX-21.2, and MX-21.3 updates as well.

You will not, however, get upgraded to MX-23 on that MX-21 machine. Moving from one major release of MX Linux to another is still a manual process and there are plenty of folks on the EOL'd MX-19.4 release today who have never been upgraded to a current version of MX. A rolling release would only offer a continuous stream of minor version updates to every user, every time they checked for patches.

In operating systems a rolling release is a very specific term to describe an OS that never provides major version milestones, and you shouldn't use it to describe a distribution that doesn't, in fact, roll from one release to the next.

Edit: article agreement

Posted: **Thu Jan 16, 2025 4:49 am**

MXMUX wrote: Thu Jan 16, 2025 3:09 am I moved from a different distro because I liked the idea of a rolling release. Less work is good, but every time the new release rolls out it breaks Nvidia. The .5 release broke it again and I went through the hoops to fix it again but it breaks again. What I mean by breaking this time is after I fixed it all was fine then on a reboot the display parameters are mess up and I cannot select a different parameter. This time when I revert to nouveau driver it sticks to 3840x2160 and my old eyes (with glasses on) can't see that. Here I go again with a re-install. With a reinstall all goes fine until an Nvidia update and it all goes downhill from there. I am fine with a re-install and wish there was a version of MX that wasn't rolling for this reason. I will look to blacklist nividia and hop this solves my problem. I am not leaving MX, Love their work but this is just an Nvidia rant.

MX is not rolling because each major release [MX19, MX21, MX23] is based on a separate Debian release [10, 11, 12], And each release has their own separate repos that will never meet or mingle. If you're on MX21/Debian 11 repos, that's where you will stay, receiving only packages compatible with these 2 releases. That's a fixed release distro. Point releases [23.1, 23.2.....] are still within the boundaries of the same Debian/MX base. Frankly, they are just names given to the latest iso/installable media so you know -- when downloading -- that you are getting the latest iso that has accumulated all the updates to date provided for that Debian/MX base.

Rolling - eg Arch Linux or Void or PCLinuxOS.
They all just have one set of repos, and newer packages just keep getting thrown into the mix of the same old repos, continuously, forever. This can cause conflicts at times, say when some devs are slower to update their packages than the rest of the packages, so it's not moving in step with everything else. And when there are major jumps in versions of certain applications or desktop environment or kernels, things can get a little hairy....

If you think Nvidia is a pain for fixed release distros like MX, wait till you try a rolling one, haha. I have Manjaro installs, and every update time, I check the forums there and there are always issues involving Nvidia. And it's not just because of new kernels being installed; the move from Plasma 5 to 6 was pretty messy for Nvidia users who wanted to use Wayland as well.....

Posted: **Thu Jan 16, 2025 6:57 am**

In any event the suggestion that you pin the Nvidia driver is a good one the other thing that may hinder Nvidia is a kernel update. which means the Nvidia driver may have to be rebuilt against the newer kernel. So sometimes it's a waiting game until everything catches up.
I stay away from Nvidia as much as possible. I'm not a gamer and don't need them. Try to enjoy the journey! :)

Posted: **Thu Jan 16, 2025 8:40 am**

As someone who has done more than my share of nVidia rants lately, some notes..

There is a sweet spot, nVidia cards that are too old and too new seem to be the most troublesome.. In my opinion serially updating a kernel with blanket upgrades is a bad idea unless there is a known security issue to be addressed.. update your apps, hold a working kernel.. Hardware support and Userspace applications are two separate worlds on a Linux system.. A solid kernel and working Drivers should theoretically last the duration of a 'Stable' Distro.. The Kernel is the core of your system and if you don't know why you're changing it, maybe don't?

Many people think otherwise and fair enough but on a production system I try and leave a working setup be with regard to the Kernel and Video Drivers.

Posted: **Thu Jan 16, 2025 11:01 am**

Debian Stable itself is rollin', rollin', rollin'---it's gone from 12.0 to 12.9! PROOF! Rolling just like my eyes:

I wonder if this was our AHS version where we do have to keep updating Nvidia to build on newer kernels, or the stable one with just Debian packages. We may never know--if only there was an easy way to quickly let us know some system information.

Posted: **Thu Jan 16, 2025 11:56 am**

@MXMUX Please post your QSI. ( MX Menu, Quick System Info, Copy for Forum, Paste here )

This will help us identify your system and *may* provide someone with the ability to suggest an upgrade strategy for you.

As an nvidia user on production machines, I prefer to do the following if there is a major nvidia update to my system.
1) Timeshift ;-/
2) update *all* drivers as I move forward on the update. (ie kernel's, nvidia, and more. )

I also have found that running Liquorix kernels help stabilize my system, as well as provide me with 'a better linux experience' , and less issues. ( your mileage may very ! but we see liquorix kernels solve issues pretty much every day in the forum. )

Posted: **Thu Jan 16, 2025 12:14 pm**

Stevo wrote: Thu Jan 16, 2025 11:01 am Debian Stable itself is rollin', rollin', rollin'---it's gone from 12.0 to 12.9! PROOF! Rolling just like my eyes:

I wonder if this was our AHS version where we do have to keep updating Nvidia to build on newer kernels, or the stable one with just Debian packages. We may never know--if only there was an easy way to quickly let us know some system information.

Right, I only consider Debian, MX, antiX, as semi-rolling (stable enough for almost everything, except especially for nvidia for the moment, but the nouveau nvidia kernel module is better and better)

Posted: **Thu Jan 16, 2025 4:37 pm**

oops wrote: Thu Jan 16, 2025 12:14 pm Right, I only consider Debian, MX, antiX, as semi-rolling

In a previous life doing consulting, I worked for a shop whose owner was a Red Hat certified engineer. Our servers ran Red Hat. Our customers bought Red Hat. We were trained on being able to evaluate a system based on the checksums of its RPMs and determine system health from it. The boss was a real Type-A guy who clearly derived deep, spiritual satisfaction from the idea of being able to conclusively, systematically test and prove that his servers were running, say, RHEL 4. Period, full-stop. The RPMs are RHEL 4 RPMs, therefore this is a RHEL 4 machine. Quod erat demonstrandum.

Eventually, we took on a customer who ran Debian, a nearly alien system to us. One of our engineers was experienced with Debian and I still remember the conversation he had with the boss explaining that Debian repos aren't segregated into "packages that were shipped on day one" and "patched packages" the way Red Hat worked. A Debian machine is a collection of the packages its installed, from whichever release branch its admin has chosen, with the option to select some things from sarge and other things from woody if one is willing to try. The idea that it was possible, and even easy, to take a sarge machine and make it somehow not a sarge machine but also not some other rigorously-defined thing, and that that was just something Debian users did, was so foreign to the boss that he buried his shocked expression into his hands and screamed one of those deep, primal screams that you only hear when a little-endian finds out someone is eating their egg wrong and getting away with it.

Further back, in the even older olden days, your operating system came on a CD-ROM or perhaps a stack of floppy diskettes and any kind of upgrade to the OS was going to involve buying another CD-ROM or stack of floppies. If your system had a bug you were stuck with it until the next service pack was released, and that might be a year away, not counting the time it would take to get your hands on the physical media to install it. Sometime around Windows 98 Microsoft started allowing users to download patches directly to their systems through a website, but I wouldn't consider Windows "semi-rolling" even today when you can, in theory, patch a Windows 10 machine to Windows 11 through the Windows Update utility if they bless the hardware.

The fact that OSes like Debian, MX, and Windows even have numbered releases is a good indication they aren't to be considered rolling. There is no "Arch 12" or "Void Linux 6.5" in large part because those projects are structured to not have a clear, exact definition of what constitutes a release. In professional software development this idea of having a period, full-stop, we-gave-it-a-special-name-and-everything Release Version is known as RTM (Release To Manufacturing[0]) or "going gold"/"golden bits". Some people love this idea for its concreteness even though system software invariably ages and becomes insecure over time. People like my old boss, for example.

All of this is context for the fact that I'm still trying to reconcile OP's conflicting statements of "I like rolling releases" and "I don't like too many updates".

[0] This is a throwback to the days when you still had to write your software to physical media, which meant mailing something to a factory to have them make your CD-ROMs or floppies for you and put them into boxes with your logo on it. The distribution process has changed but the term persists. This is also why some people still use the term "shipping" in software, as in "Looks good. Ship it.", meaning you've entirely completed the task of making the software and now it's someone else's responsibility to get it into stores and onto retailers' shelves.

Posted: **Thu Jan 16, 2025 6:54 pm**

DukeComposed wrote: Thu Jan 16, 2025 4:37 pm If your system had a bug you were stuck with it until the next service pack was released, and that might be a year away

I have no computer education or credentials nor have I ever been employed in any aspect of the computer business so I'm the last person to ask how things should be done but my first installed Linux Distro was Mepis but just before that there was a Live Boot Linux built on Slackware called 'Dynebolic' and it was geared to turning any computer into a multimedia production studio which in 2006 was pretty audacious since the number and progression of the applications was laughable in comparison to Windows and OSX. Dynebolic used some sort of nesting trick so you could make room for it and run it in your Windows install without fully installing and dual booting (perhaps MX/antiX 'frugal' is sorta similar). Anyway the concept was fascinating to me, at that point it didn't really have Repos so you got what you got until they made a newer one but the concept was very cool to me, a way to make any computer into an immutable recording and production appliance, just work like you were using a toaster, no updates no changes, turn it on every day to the same degree of reliable experience.. Of course human nature, FOMO and the neurotic drive of developers to develop and Users to thirstily upgrade made the whole thing a non-starter but I still love the concept and use it in our recording Studio where a reduced and carefully curated and apt-pinned AV Linux is installed and used for a few years at a time, no Kernel updates, browser-only updates and leaving the DE and support components as undisturbed as possible and VERY carefully considered updates of the recording software and Plugins and always a custom package of every version used for rollbacks if needed.. In stark relief to a development machine where everything new must be evaluated and tried out before unleashing on Users and where things like a Video card upgrade (looking at you nVidia!) can completely upset the apple cart..

Posted: **Thu Jan 16, 2025 7:29 pm**

DukeComposed wrote: Thu Jan 16, 2025 4:37 pm...
[0] This is a throwback to the days when you still had to write your software to physical media, which meant mailing something to a factory to have them make your CD-ROMs or floppies for you and put them into boxes with your logo on it. The distribution process has changed but the term persists. This is also why some people still use the term "shipping" in software, as in "Looks good. Ship it.", meaning you've entirely completed the task of making the software and now it's someone else's responsibility to get it into stores and onto retailers' shelves.

For me, it is a good practice to have a computer product (or other) that evolves with versions and fixes over several years (for a LTS support), without disturbing its stability too much. Besides, Android works like that too, it is not frozen, it is not rolling, it is semi-rolling, in this way it leaves more time to be able to develop another innovative product with more fundamental changes.
It is a good strategy and a good compromise in my opinion (a semi-rolling behavior like Debian , MX and antiX have).

Posted: **Thu Jan 16, 2025 8:54 pm**

In my opinion, any distro where you have to switch repos to upgrade to a newer major release cannot be called rolling., semi or otherwise.

But maybe that's just me.

So I don't consider MX or Debian stable to be rolling. While Debian Testing and unstable are rolling.

PCLinuxOS, I've heard called semi rolling. Same set of repos throughout, but there's less churn. "Normal" packages tend to be updated regularly, but major updates of core packages (the glibc, GTK, qt,, major DE upgrade type of thing) are held back for some time until the devs feel it's pretty stable, and then there'll be one big upgrade dropped. Based on this type of behaviour I would call Solus semi rolling as well.

Posted: **Sat Jan 18, 2025 8:38 pm**

Well, what IS nice is that Nvidia has just made their drivers basically open-source, so in the future, this should greatly help with cutting out the usual Nvidia nonsense you see on Linux.

Posted: **Tue Jan 21, 2025 2:42 am**

Wow a lot of replies in this, sorry for the delay in responding as I was fighting with my problem which I resolved. After a kernel and nvidia driver update an app I run a lot stopped working with this error

Code: Select all

GLFW error 65542: GLX: No GLXFBConfigs returned.

Please make sure you have up-to-date drivers (see aka.ms/mcdriver for instructions).

so I assumed the nvidia update to be at fault. Chasing my rear end around in circles for a long time I ranted on here not expecting the amount of response that I got since I was just ranting, well I was wrong again on that too. The app is Prism Launcher and it gave the error above. So to cure the problem all I had to do was ref a newer flatpack of Prism and upgrade it also. As to why it doesn't the newer GLFX that's over my head. I did manage to get it to work. I like to try to fix things myself so I was away from the forum here all this time chasing my rear end around in circles. Thank all who were trying to help though.

Code: Select all

System:
  Kernel: 6.1.0-30-amd64 [6.1.124-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-30-amd64 root=UUID=<filter> ro quiet splash
  Desktop: Xfce v: 4.20.0 tk: Gtk v: 3.24.38 info: xfce4-panel wm: xfwm v: 4.20.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.5_x64 Libretto May 19  2024 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Desktop Mobo: ASRock model: B450M-IBW serial: <superuser required>
    UEFI: American Megatrends v: P1.70 date: 12/17/2019
CPU:
  Info: model: AMD Ryzen 7 3700X bits: 64 type: MT MCP arch: Zen 2 gen: 3 level: v3 note: check
    built: 2020-22 process: TSMC n7 (7nm) family: 0x17 (23) model-id: 0x71 (113) stepping: 0
    microcode: 0x8701013
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache: L1: 512 KiB
    desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 32 MiB desc: 2x16 MiB
  Speed (MHz): avg: 2183 high: 2254 min/max: 2200/4426 boost: enabled scaling:
    driver: acpi-cpufreq governor: ondemand cores: 1: 2114 2: 2086 3: 2092 4: 2200 5: 2200 6: 2200
    7: 2200 8: 2200 9: 2196 10: 2200 11: 2195 12: 2254 13: 2196 14: 2196 15: 2200 16: 2200
    bogomips: 114981
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed mitigation: untrained return thunk; SMT enabled with STIBP protection
  Type: spec_rstack_overflow mitigation: safe RET
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines; IBPB: conditional; STIBP: always-on; RSB filling;
    PBRSB-eIBRS: Not affected; BHI: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA TU106 [GeForce RTX 2070] vendor: Micro-Star MSI driver: nvidia v: 535.216.01
    non-free: 530.xx+ status: current (as of 2023-03) arch: Turing code: TUxxx process: TSMC 12nm FF
    built: 2018-22 pcie: gen: 3 speed: 8 GT/s lanes: 16 bus-ID: 06:00.0 chip-ID: 10de:1f02
    class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.20.0 driver: X: loaded: nvidia
    unloaded: fbdev,modesetting,nouveau,vesa alternate: nv gpu: nvidia display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 509x286mm (20.04x11.26") s-diag: 584mm (22.99")
  Monitor-1: DP-4 res: 1920x1080 hz: 75 dpi: 82 size: 597x336mm (23.5x13.23")
    diag: 685mm (26.97") modes: N/A
  API: OpenGL v: 4.6.0 NVIDIA 535.216.01 renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2
    direct-render: Yes
Audio:
  Device-1: NVIDIA TU106 High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel
    v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16 bus-ID: 06:00.1 chip-ID: 10de:10f9 class-ID: 0403
  Device-2: AMD Starship/Matisse HD Audio vendor: ASRock driver: snd_hda_intel v: kernel pcie:
    gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 08:00.4 chip-ID: 1022:1487 class-ID: 0403
  API: ALSA v: k6.1.0-30-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi v: kernel modules: wl
    pcie: gen: 1 speed: 2.5 GT/s lanes: 1 bus-ID: 03:00.0 chip-ID: 8086:24fb class-ID: 0280
  IF: wlan0 state: down mac: <filter>
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASRock driver: r8169
    v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: f000 bus-ID: 04:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Bluetooth:
  Device-1: Intel Wireless-AC 3168 Bluetooth type: USB driver: btusb v: 0.8 bus-ID: 1-1:2
    chip-ID: 8087:0aa7 class-ID: e001
  Report: hciconfig ID: hci0 rfk-id: 1 state: up address: <filter> bt-v: 2.1 lmp-v: 4.2
    sub-v: 1100 hci-v: 4.2 rev: 1100
  Info: acl-mtu: 1021:4 sco-mtu: 96:6 link-policy: rswitch sniff link-mode: peripheral accept
    service-classes: rendering, capturing, object transfer, audio, telephony
Drives:
  Local Storage: total: 3.21 TiB used: 136.34 GiB (4.2%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: A-Data model: SU800 size: 953.87 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 8B scheme: GPT
  ID-2: /dev/sdb maj-min: 8:16 vendor: Western Digital model: WD10PURZ-85U8XY0 size: 931.51 GiB
    block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 5400 serial: <filter>
    rev: 1A01 scheme: GPT
  ID-3: /dev/sdc maj-min: 8:32 vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB
    block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 4B6Q
    scheme: GPT
  ID-4: /dev/sdd maj-min: 8:48 vendor: Western Digital model: WD10EZEX-08WN4A0 size: 931.51 GiB
    block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 serial: <filter>
    rev: 1A01 scheme: GPT
Partition:
  ID-1: / raw-size: 50 GiB size: 48.91 GiB (97.83%) used: 23.14 GiB (47.3%) fs: ext4 dev: /dev/sda2
    maj-min: 8:2
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%) used: 288 KiB (0.1%) fs: vfat
    dev: /dev/sda1 maj-min: 8:1
  ID-3: /home raw-size: 300 GiB size: 294.23 GiB (98.08%) used: 38.39 GiB (13.0%) fs: ext4
    dev: /dev/sda3 maj-min: 8:3
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 2 GiB used: 0 KiB (0.0%) priority: -2 file: /swapfile
Sensors:
  System Temperatures: cpu: 55.9 C mobo: N/A gpu: nvidia temp: 33 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 31%
Repos:
  Packages: 2620 pm: dpkg pkgs: 2606 libs: 1409 tools: apt,apt-get,aptitude,nala,synaptic pm: rpm
    pkgs: 0 pm: flatpak pkgs: 14
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://mirrors.rit.edu/mxlinux/mx-packages/mx/repo/ bookworm main non-free
  No active apt repos in: /etc/apt/sources.list.d/prebuilt-mpr.list
  No active apt repos in: /etc/apt/sources.list.d/steam-beta.list
  Active apt repos in: /etc/apt/sources.list.d/steam-stable.list
    1: deb [arch=amd64,i386 signed-by=/usr/share/keyrings/steam.gpg] https://repo.steampowered.com/steam/ stable steam
    2: deb-src [arch=amd64,i386 signed-by=/usr/share/keyrings/steam.gpg] https://repo.steampowered.com/steam/ stable steam
Info:
  Processes: 353 Uptime: 34m wakeups: 1 Memory: 15.54 GiB used: 2.1 GiB (13.5%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

Posted: **Tue Jan 21, 2025 4:08 am**

Please click the checkmark in the top right of the post (to the left of the username/user image) that holds the solution to mark the topic solved, thanks :)

Posted: **Tue Feb 04, 2025 6:44 am**

kc1di wrote: Thu Jan 16, 2025 6:57 am In any event the suggestion that you pin the Nvidia driver is a good one the other thing that may hinder Nvidia is a kernel update. which means the Nvidia driver may have to be rebuilt against the newer kernel. So sometimes it's a waiting game until everything catches up.
I stay away from Nvidia as much as possible. I'm not a gamer and don't need them. Try to enjoy the journey! :)

Agree. I’m on NVIDIA now and have made up my mind to move to an AMD card once they support ollama better (running your own LLM chatbot).

I’ve gotten bitten (not on MX but in Debian) with not having the generic kernel headers installed right and then having the kernel module not get generated and only not finding this out until I reboot and then my desktop not come up

MX Linux Forum

NVIDIA Rant. (Reload Prism Launcher)

NVIDIA Rant. (Reload Prism Launcher)

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant.

Re: NVIDIA Rant. (reload Prism Launcher) [Solved]

Re: NVIDIA Rant. (Reload Prism Launcher) Solved

Re: NVIDIA Rant.