Mister László, IT WORKED!!
Damn!
I got my Ubuntu Maté back!
For those of you kinda weary of reading all the dialog, I can summarize in a few clear steps (my ESL teacher hat in full view, y’all!)
I. What is missing?
Harder than it sounds. In my case, there were two competing software packages, both installed. One was nvidia proprietary, the other xorg drivers.
Turns out that the xorg drivers, code-name nouveau, are the default beginning with Ubuntu 22.04.
But it also turns out that the software is irrelevant. What I was missing was modules loaded into initramfs during boot.
II. Loading the Missing Module(s)
Two steps did it. Step #1 is to look into the blacklists that Ubuntu creates, found in
/etc/modprobe.d
and disable the blacklist keeping the graphics modules from loading. In my case, it was a single file, called nvidia-blacklists-nouveau.conf
To disable it, the safe method is to rename it (command mv) with a disabling extension, in my case
nvidia-blacklists-nouveau.conf.bak
Step #2 is to refresh the initramfs with the module that SHOULD have loaded in the first place, like this:
update-initramfs -u
It worked on first reboot. Let’s see what happens tomorrow.
Mister Akito, I think I understand what happened. See if my “humanities” background understanding fits the occasion.
The original sin is that there were two competing sets of drivers/modules. Until 22.04, a Linux distro could, and probably did, make both available. This is dangerous, 'cause it opens up lots of ways for users to make innocent mistakes with serious consequences.
With this upgrade in place (Maté from 20 to 22, while it is still running), Nvidia proprietaries were in place, loaded and working. This led to the Ubuntu upgrade blacklisting the GOOD drivers (nouveau), and then not recognizing the OBSOLETE drivers (nvidia), because the nvidia ones were in play.
My solution to the Canonical team would be, require cross-version upgrades to be done from terminal, not in place. If I had rebooted to command prompt and run the distro upgrade that way, the blacklist file would not have been created.
Feedback?
I think, such errors shouldn’t be possible to happen, in the first place. The operating system should stop the user from doing something “the wrong way” according to the operating system.
Last week i bought a chain saw with a twisted handle. Perhaps i wasn’t careful, but by accident it chopped one of my arm off, then i thought to myself “gosh, this is POWERFUL!”. This seems to be the fashionable mode of thinking among the unixers or unixer-to-be, who would equate power and flexibility with rawness and complexity; disciplined by repeated accidents.
— Xah Lee
This is what I think of, when people say you can do anything you want on Linux.
Despite everything I said, it’s great to hear that you found the right solution to your issue, if it works as intended.
Is your solution confirmed to work?
First reboot from recovery mode, yes.
Second reboot, warm from the first boot, also yes.
The only thing I have not done is a cold reboot. Check in with me later for bad news.
Mister Lazlo, I have created that file and put it in the same directory. We’ll see.
Before, there was a tip on another help site that said the following command would help:
nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"
It reduced tearing, but did not eliminate it.
My tearing is mildly annoying, and only intrudes when scrolling in a browser. I’ll let you know.
Debians release cycle is 18 months
That is an argument for rolling release distros
@cliffsloane … There is one answer for you Cliff
Forget about nvidia drivers and do this patch to make nouveau drivers work better.
You can try it in Mint21, then if you like it, put the nouveau drivers into Ubuntu22
Thank you @kovacslt , he has some options now
Regards
Neville
OK, I understand that, thank you.
Compatability with the kernel is a much bigger issue than minor video tearing
Regards
Neville
Well in this case it is starting to look like it is actually the proprietary software that is at fault.
Nvidia drivers have kernel compatability issues.
I would say anything from major kernel problems to success could be the outcome. No idea of your chances.
If you want to still try, lets first check that they really are blacklisted.
What do you have in /etc/modprobe.d ?
Otherwise, your steps look ok
I would try first the option @kovacslt gave you to fix the tearing with thw nouveau drivers. You can try that in Mint21. Easy to do.
If that works, I would put the nouveau drivers into Ubunto22
Regards
Neville
If LInux would focus more on design and UX, more people would use it. If more people would use it, then that operating system would be considered more popular and its market share would increase. Once it would break a certain threshold on the market, companies would receive a financial incentive in dedicating more resources into making stuff work on that particular operating system.
So, if Linux is not being a proper end-user product, then it barely may complain about NVIDIA doing its thing. I also am a 100% sure, that AMD is not doing the open source stuff out of pure altruism. It’s most likely related to how NVIDIA dominates the market, so AMD needs other straws and boni, to make a proper competition. (Focusing on graphics cards.)
I can easily imagine, that if there were a new operating system, which primary goal would be to make all hardware work perfectly, just as on Windows and they would actually be doing that and not only dreaming of it, it would become by far the most popular Linux OS for end-users, surpassing Ubuntu without effort, within a year.
Hell, if such a Linux OS would exist and it would actually live up to that primary goal, I would switch right now.
If Linux OS would support my hardware just as well as Windows, I would literally ditch Windows right in this moment and make that new Linux OS work.
Sadly, this is, as it seems for so many years now, just a dream.
My long story short:
If Linux would work, I would use it. But it does not work, if you have any hardware that is slightly more special or recent than what the Linux OS teams expect or know of.
As a reminder: I could not even order my multi-monitor setup for good. On every reboot I had to re-order the screens, so they fit. And even then, I could not use all screens, because Linux was too stupid to use my dedicated and integrated graphics card at the same time. You could only use either.
On Windows, I use both at the same time since years. No (re-)configuration needed. Ever. Not even after a graphics card driver upgrade!
In my experience, Linux GUI was always Forrest Gump sitting on that famous bench. You never know what you get. Every time you boot up the system, something else breaks, plus the stuff that breaks on every boot.
It’s like a lottery, where you pretty much always lose. Okay, so, basically like a real lottery.
What baffles me most about this is that I’m not a newbie. I have tons of experience with Linux, that I gathered over the years.
I have rarely trouble with GUI-less Linux. It works, as it should and I can handle advanced configurations.
However, whenever it comes to GUI-full Linux, everything starts to break and not even my Linux experience helps, because everything is so mixed up & senseless, you can only sit there for hours, performing the Linux ritual of trial & error, until you find a workaround by accident. I do not have and do not want to have time for this.
That is it.
Linux made a mistake trying to emulate the Windows/Apple user interface. It should have invented its own unique interface.
Go back to the dumb terminal stage and start again
Cliff, thats great. And thanks for the summary.
I wat tonarchive some of this fir future reference.
It will happen again.
And thanks you @kovacslt
Your expertese was needed
Regards Neville
The better solution is to not use fixed release distros.
Rolling release eliminates these cross-release upgrade issues
Ubuntu has a rolling release… use that and you will never have to upgrade again
And… having two drivers present as packages should not be a problem
It is only those added as kernel modules that are active.
In your case neither of the two sets of drivers were active
The original sin was changing the video card… You ate the forbidden nvidia fruit
I had a look at UbuntuUpdates - Package "nvidia-340" (jammy 22.04)
It says: Transitional package for xserver-xorg-video-nouveau
That package originally stores the closed-source drivers for nvidia.
The current package delivers the opensource nouveau driver for nvidia.
So when upgrading from 20.04 to 22.04 the proprietary drivers were silently upgraded to nouveau - if I understand correctly.
When you do an inplace upgrade, the upgrade process is done by do-release-upgrade at the end, no matter you started it from a GUI frontend by clicking a button, or from a terminal by issuing the command.
Such an upgrade keeps all your data, and settings, including system-wide settings.
Usually that’s OK, as nobody want to reconfigure the whole system after an upgrade. That would mean a clean install rather than upgrade 
Just to clarify: by in-place upgrade I mean, doing the upgrade from the running system itself, updating the packages, while keeping all data and settings…
A “normal” upgrade was basically a clean install, and migrate data and settings afterwars.
The problem was that the nouveu driver was previously blacklisted by nvidia prop. install - reasonably. I think, the new nvidia-340 package should have a check for nouveau being blacklisted, and I think the bug is here: it does not.
grep -Ril 'blacklist nouveau' /etc/modprobe.d/ Returns the files where nouveau is blacklisted - hopefully only one 
Renaming those files would have saved @cliffsloane from his adventure.
I’m not a maintainer of any Ubuntu packages, but I’d add int post-install script something like that:
filenames=`grep -Ril 'blacklist nouveau' /etc/modprobe.d/`
for eachfile in $filenames
do
mv $eachfile $eachfile.bak
done
(Script not tested, just an example…)
So yes, there’s a bug int Ubuntu’s upgrade path, and @cliffsloane was hit by this bug.
The sad news for @Akito , this is NOT a bug in GUI. 
Well, depends on the definition. I usually talk about something breaking, when using GUI. It’s not like every bug is 100% part of GUI code.
In this case we are talking about graphics cards. So, I would never encounter this issue on any of my servers, as they naturally don’t have any graphics units installed.
That’s apparently false. If that was true, nobody could use Linux with a GUI.
There would be no working
- MATE
- XFCE
- KDE
- LXDE
- Budgie
just unusable broken “utter shits”.
Thanks for volunteer developers, this is not the case. All those GUI’s are usable, some of them are really mature, others still in “beta”.
Maybe you should get some more?
If something brakes, it may take some time to repair.
Over here I get at least 2 computers a month to fix. It’s always Windows…
It’s not that Linux doesn’t brake -it doesn’t brake for me, but broke for @cliffsloane for example- but the same applies to that monolithic OS too, it doesn’t brake for you, but brake for many others.
Just because you did not have a major problem with Windows, doesn’t mean, it’s always perfect. Linux isn’t perfect as well. According to bugtracker, Debian has about 80000 bugs at the moment… It’s far from perfect. Still the best OS I ever met. The most reliable workhorse I know. Yes, with a GUI, because when using, I like the clickety-click-click-drag-drop.
When administrating, the terminal is more practical.
Windows too has tons of options unavailable on GUI. That’s why the registry hacks exist…
They are broken though and do not work. I think we have different definitions of “work”. Additionally, I wasn’t talking only about DEs, but about the whole GUI universe.
So, to use Linux GUI, the user has to be a Kernel developer, have decades of experience with Linux, know Linux and DE code by heart, etc… Wow, what a usable “not broken” GUI. 
It should not break, to begin with.
If a million people use Windows and only 100 use Linux, then naturally you will get more cases on Windows. Additionaly, Windows almost never breaks. It’s usually some misconfiguration. However, on Windows, you don’t need advanced scripting and Linux skills to apply the simplest settings, as it is the case on Linux.
I still find it fascinating, that Linux still has no option of never using the CLI ever, whereas on Windows it’s perfectly normal to not open the terminal Window for decades.
I literally never claimed anything was perfect. Though, you are committing a fallacy by comparing the two like that. “Windows breaks once in ten years, so it’s not perfect. Linux breaks every day, so it’s not perfect either. See, they are both equally broken.” That point is just plain wrong.
I am talking about end-user stuff. On Windows you don’t need administration for end-users, because shit just works!!
Wrong. Pretty much everything is available via GUI. The only things you need registry hacks for are deprecated features or unintended behaviour.
I would say that is a natural consequence of linux being open source while windows is closed shop
There really is hardly anything one can usefully do at a terminal in windows, because there is no access to code , so one can never understsand how it works or what might be usefully changed.