I pushed 495.44 drivers to unstable without pre-compiled extramodules. Users might need to install nvidia-dkms package after removing any linuxXXX-nvidia package before. Pre-compiled packages may come later this week.
EDIT: Dont forget to run sudo mkinitcpio -P after.
Anyway, I think discarding 470 drivers when 495/latest drivers are pushed to Stable would be a mistake. That would mean people should use the 390 drivers, which are not really good at all, or not compatible at all with some currently working software (rendering, encoding, gaming, things important for users with Nvidia cards, most of the time).
I really think creating an additional video-nvidia-470xx driver for MHWD, when 495 hits Stable, would be a good move for all concerned people. It is not like recreating the nightmare when there was half a dozen drivers versions to maintain, it is keeping LTS drivers alive to keep proper support for all users.
At minimum Manjaro should provide a solution, like the DKMS package made for the 340 drivers, to not say to these concerned users.
PS: it is not even for me, I don’t care I don’t have old video card.
After removing linux514-nvidia and installing nvidia-dkms, the machine couldn’t boot my display manager. It got stuck before showing anything graphical except the useless short text about a filesystem scan, without telling me anything important about booting there. I had to manually switch to a TTY and look in the journal with journalctl -R and scroll down a few pages to find the error, which was an error about kernel module version mismatches. (I wish it would have just printed that error directly instead of requiring that.)
From my research about the error, I found that I had to type sudo mkinitcpio -P, wait for that to finish, then reboot again from a TTY (get there with Ctrl+Alt+F2) for booting to the display manager to succeed again. This short comment is to help anyone who had the same issue.
Edit: Phil’s updated this comment’s parent comment with this solution as well.
Yeah, I just hit this while trying to upgrade packages and removed my linux510 (had it as backup but never really needed ant it blocked upgrading to nvidia 495.44) but then ended up without linux514-nvidia installed. No biggie - was going to re-install that and bam - target not found…
Since the 495 driver has key Wayland support improvements, it would be good to have this available as a ‘normal’ kernel module on the unstable branch for those who want it.
@oberon is current working on the extramodules for 495 driver series. We had some low staffing this week due to some vacations and other things going on. For sure the modules may be online in some hours …
Has anyone been able to get Plasma 5.23.2 desktop to be GPU accelerated with Nvidia in the Wayland session? Whenever I log in to Plasma Wayland with Nvidia 495.44 installed, Plasma renders with llvmpipe, X works as intended. Reverting to 47x fixes Wayland (uses my GTX 1060 instead of llvmpipe)
Tried different kernels, made sure my modesetting config was correct, checked package versions for stuff such as xwayland and egl-wayland, all up to date.
Usually I’m a patient soul; but this GBM support has me drooling, lol
Seems we’re waiting for an egl-wayland and Qt update for this to work properly, so for now we have to use EGLStreams for just a little bit longer. Solution in link.
Seems OK with systemd hook. Will reboot now and see, but I already can tell that udev-based initramfs’ images I have now are slightly smaller than systemd-based ones, which is the opposite of what it used to be on my machine.
Hilariously both have “Image generation successful” report at the end
PS: the last batch of updates I’m talking about contained these packages:
To avoid such issues and feel a bit pro (only a lil bit though) you guys can use a cool trick to generate both udev- and systemd-based initrds when updating kernels, cryptsetup and other stuff that triggers initrds’ rebuild:
Do cp /etc/mkinitcpio.conf /etc/mkinitcpio.systemd.conf
Open /etc/mkinitcpio.systemd.conf with some editor
Find HOOKS section
Make it look like this: HOOKS=(base systemd keyboard sd-vconsole autodetect sd-plymouth modconf block sd-plymouth-tpm2-totp sd-encrypt lvm2 filesystems)
instead of this: HOOKS=(base udev keyboard consolefont autodetect plymouth modconf block plymouth-tpm2-totp tpm2 plymouth-encrypt lvm2 resume filesystems)
Basically just do as Arch Wiki suggests. I’m writing “like” because the above reflects my set of hooks, yours may be very different. You need a general understanding what you’re doing that’s why I mentioned Arch Wiki as a reference.
After saving that file, navigate to /etc/mkinitcpio.d and open any preset there, say, linux515.preset.
Modify the line PRESETS=('default' 'fallback') to PRESETS=('default' 'systemd')
Done! Now every time you initiate mkinitcpio manually or by pacman hook (during installing updates) mkinitcpio will build 2 initrds for linux 5.15: udev-based and systemd-based. If something goes bad and you won’t be able to boot all you need to do is to select 5.15 entry in Grub menu, press E, modify initramfs path from initramfs-5.15-x86_64.img to initramfs-5.15-x86_64-systemd.img and press Ctrl + X to boot.
Of course there are other obstacles if you are using encryption for example, but you got the general idea I guess. Edit Grub’s cmdline too, if needed. Or you can go further and add a respective entry to Grub / systemd-boot menu if you want. That’s another story though.
As you can see, issue “got fixed” right upon installing (downgrading to) the previous version of lvm2. So I guess you’re doing it wrong.
You’d better quit Unstable branch if you can’t downgrade or else one day you gonna bork your install irrevocably.
UPD: Ah I’m sorry too, I see now how your set up is done. No plymouth-encrypt hook I suppose but encrypt instead…