[Unstable Update] 2021-10-23 - Kernels, Nvidia, Haskell, Kodi, Thunderbird, PHP, Wine

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. :wink:

3 Likes

Seems the GSYNC issue has indeed been fixed in 470.82 :partying_face:

1 Like

Hmm, maybe we should go then for that release series and wait a little longer for 495 and beyond. Let’s see.

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 :fu: to these concerned users.

PS: it is not even for me, I don’t care I don’t have old video card.

7 Likes

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.

Currently we have this situation with Nvidia drivers:

:: Different overlay package(s) in repository community x86_64

-------------------------------------------------------------------------------
                             PACKAGE       stable-staging             unstable
-------------------------------------------------------------------------------
                  linux510-rt-nvidia          470.82.00-1                    -


:: Different overlay package(s) in repository core x86_64

-------------------------------------------------------------------------------
                             PACKAGE       stable-staging             unstable
-------------------------------------------------------------------------------
                         mhwd-nvidia          470.82.00-1             495.44-1


:: Different overlay package(s) in repository extra x86_64

-------------------------------------------------------------------------------
                             PACKAGE       stable-staging             unstable
-------------------------------------------------------------------------------
           gsettings-desktop-schemas               40.0-3                    -
                          libxnvctrl          470.82.00-1             495.44-1
                     linux414-nvidia          470.82.00-1                    -
                     linux419-nvidia          470.82.00-1                    -
                      linux44-nvidia          470.82.00-1                    -
                      linux49-nvidia          470.82.00-1                    -
                     linux510-nvidia          470.82.00-1                    -
                     linux513-nvidia          470.82.00-1                    -
                     linux514-nvidia          470.82.00-1                    -
                     linux515-nvidia        470.82.00-0.1                    -
                      linux54-nvidia          470.82.00-1                    -
                         nvidia-dkms          470.82.00-1             495.44-1
                        nvidia-utils          470.82.00-1             495.44-1
                       opencl-nvidia          470.82.00-1             495.44-1


:: Different sync package(s) in repository extra x86_64

-------------------------------------------------------------------------------
                             PACKAGE       stable-staging             unstable
-------------------------------------------------------------------------------
           gsettings-desktop-schemas                    -               41.0-1


:: Different overlay package(s) in repository multilib x86_64

-------------------------------------------------------------------------------
                             PACKAGE       stable-staging             unstable
-------------------------------------------------------------------------------
                  lib32-nvidia-utils          470.82.00-1             495.44-1
                 lib32-opencl-nvidia          470.82.00-1             495.44-1

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

So that’s a bit of a pickle…

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.

Thanks to plilm and buju followed the info rebooted and on latest nvidia drivers.

1 Like
 core                                                                                174.4 KiB   167 KiB/s 00:01 [###################################################################] 100%
 extra                                                                              1905.0 KiB  1790 KiB/s 00:01 [###################################################################] 100%
 community                                                                             6.7 MiB  5.16 MiB/s 00:01 [###################################################################] 100%
 multilib                                                                            177.1 KiB   873 KiB/s 00:00 [###################################################################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing nvidia-utils (495.44-1) breaks dependency 'nvidia-utils=495.29.05' required by linux513-nvidia
:: installing nvidia-utils (495.44-1) breaks dependency 'nvidia-utils=495.29.05' required by linux514-nvidia

@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 …

3 Likes

Due to this.

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

Edit: https://www.reddit.com/r/archlinux/comments/qgh5cb/if_youre_using_wayland_nvidia_495_driver_on_kde/?utm_medium=android_app&utm_source=share

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.

Some urgent info for all “Unstablers”:

The latest series of updates will make your system unbootable if you’re using LVM and udev-based initramfs. Here is what I’m looking at right now:

Building image from preset: /etc/mkinitcpio.d/linux514.preset: 'default'
  -> -k /boot/vmlinuz-5.14-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.14-x86_64.img
==> Starting build: 5.14.14-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [keyboard]
  -> Running build hook: [consolefont]
  -> Running build hook: [autodetect]
  -> Running build hook: [plymouth]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [plymouth-tpm2-totp]
  -> Running build hook: [tpm2]
  -> Running build hook: [plymouth-encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
  -> Running build hook: [lvm2]
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/install/lvm2: line 33: add_udev_rule: command not found
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-5.14-x86_64.img
==> Image generation successful

This was udev-based initramfs.
Now let’s move to systemd-based:

==> Building image from preset: /etc/mkinitcpio.d/linux514.preset: 'systemd'
  -> -k /boot/vmlinuz-5.14-x86_64 -c /etc/mkinitcpio.systemd.conf -g /boot/initramfs-5.14-x86_64-systemd.img
==> Starting build: 5.14.14-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [keyboard]
  -> Running build hook: [sd-vconsole]
  -> Running build hook: [autodetect]
  -> Running build hook: [sd-plymouth]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [sd-plymouth-tpm2-totp]
  -> Running build hook: [sd-encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
  -> Running build hook: [lvm2]
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-5.14-x86_64-systemd.img
==> Image generation successful

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 :crazy_face:

PS: the last batch of updates I’m talking about contained these packages:

python-pexpect (4.8.0-3 -> 4.8.0-4)
python-ptyprocess (0.7.0-1 -> 0.7.0-2)
python-cachetools (4.2.3-1 -> 4.2.4-1)
openexr (3.1.2-1 -> 3.1.3-1)
lvm2 (2.03.13-1 -> 2.03.14-1)
cryptsetup (2.4.1-1 -> 2.4.1-3)
device-mapper (2.03.13-1 -> 2.03.14-1)

EDIT:
Yep, as expected, system is unbootable with udev initramfs, but works fine with systemd-based one.

There’s a command add_udev_rule in updated lvm2 hook, but /usr/lib/initcpio/functions has no such command:

3 Likes
Got the same `command not found` while update
$ pamac update
Preparing...
Synchronizing package databases...
Refreshing core.db...                                                                                                                                                                        
Refreshing extra.db...                                                                                                                                                                       
Refreshing community.db...                                                                                                                                                                   
Refreshing chaotic-aur.db...                                                                                                                                                                 
Resolving dependencies...                                                                                                                                                                    
Checking inter-conflicts...

To upgrade (4):
  device-mapper  2.03.14-1  (2.03.13-1)  core   300.3 kB
  cryptsetup     2.4.1-3    (2.4.1-1)    core   601.7 kB
  lvm2           2.03.14-1  (2.03.13-1)  core   1.6 MB
  openexr        3.1.3-1    (3.1.2-1)    extra  1.2 MB

Total download size: 3.7 MB
Total installed size: 103.1 kB

Apply transaction ? [y/N] y
Download of openexr (3.1.3-1) started                                                                                                                                                        
Download of device-mapper (2.03.14-1) started                                                                                                                                                
Download of device-mapper (2.03.14-1) finished                                                                                                                                               
Download of cryptsetup (2.4.1-3) started                                                                                                                                                     
Download of openexr (3.1.3-1) finished                                                                                                                                                       
Download of cryptsetup (2.4.1-3) finished                                                                                                                                                    
Download of lvm2 (2.03.14-1) started                                                                                                                                                         
Download of lvm2 (2.03.14-1) finished                                                                                                                                                        
Checking keyring...                                                                                                                                                                     [4/4]
Checking integrity...                                                                                                                                                                   [4/4]
Loading packages files...                                                                                                                                                               [4/4]
Checking file conflicts...                                                                                                                                                              [4/4]
Checking available disk space...                                                                                                                                                        [4/4]
Upgrading device-mapper (2.03.13-1 -> 2.03.14-1)...                                                                                                                                     [1/4]
Upgrading cryptsetup (2.4.1-1 -> 2.4.1-3)...                                                                                                                                            [2/4]
Upgrading lvm2 (2.03.13-1 -> 2.03.14-1)...                                                                                                                                              [3/4]
Upgrading openexr (3.1.2-1 -> 3.1.3-1)...                                                                                                                                               [4/4]
Running post-transaction hooks...
Reloading system manager configuration...                                                                                                                                               [1/5]
Reloading device manager configuration...                                                                                                                                               [2/5]
Arming ConditionNeedsUpdate...                                                                                                                                                          [3/5]
Updating linux initcpios...                                                                                                                                                             [4/5]
==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'default'
  -> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64.img
==> Starting build: 5.15.0-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.15-x86_64.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'fallback'
  -> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64-fallback.img -S autodetect
==> Starting build: 5.15.0-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [encrypt]
==> WARNING: Possibly missing firmware for module: qat_4xxx
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
/usr/lib/initcpio/functions: line 196: add_udev_rule: command not found
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.15-x86_64-fallback.img
==> Image generation successful
Refreshing PackageKit...                                                                                                                                                                [5/5]
A restart is required for the changes to take effect.
Transaction successfully finished.
$

I saw this too late and I rebooted my machine, now I can’t recover.
I am sorry but does anyone know a good way to recover?

Chroot to your system from live OS and downgrade lvm2 and cryptsetup packages.

@alven do not reboot :stuck_out_tongue_winking_eye:

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:

  1. Do cp /etc/mkinitcpio.conf /etc/mkinitcpio.systemd.conf
  2. Open /etc/mkinitcpio.systemd.conf with some editor
  3. Find HOOKS section
  4. 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.
  5. After saving that file, navigate to /etc/mkinitcpio.d and open any preset there, say, linux515.preset.
  6. Modify the line PRESETS=('default' 'fallback') to PRESETS=('default' 'systemd')
  7. Add there the following:
systemd_config="/etc/mkinitcpio.systemd.conf"
systemd_image="/boot/initramfs-5.15-x86_64-systemd.img"
#systemd_options=""

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.

2 Likes

I downgraded but I am still seeing add_udev_rule issues
in initcpio functions.

Huh?

Summary
┬─[openm@reiwa:~]─[01:01:24]
╰─>$ sudo downgrade lvm2
Available packages (core):

-   1)  lvm2    2.02.183  2  remote
...
-  20)  lvm2    2.03.12   1  remote
-  21)  lvm2    2.03.13   1  remote
+  22)  lvm2    2.03.14   1  remote
+  23)  lvm2    2.03.14   1  /var/cache/pacman/pkg

select a package by number: 21
:: Retrieving packages...
 lvm2-2.03.13-1-x...  1530.7 KiB   846 KiB/s 00:02 [#########################] 100%
loading packages...
warning: downgrading package lvm2 (2.03.14-1 => 2.03.13-1)
resolving dependencies...
looking for conflicting packages...

Packages (1) lvm2-2.03.13-1

Total Installed Size:   6.17 MiB
Net Upgrade Size:      -0.07 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                     [#########################] 100%
(1/1) checking package integrity                   [#########################] 100%
(1/1) loading package files                        [#########################] 100%
(1/1) checking for file conflicts                  [#########################] 100%
(1/1) checking available disk space                [#########################] 100%
:: Processing package changes...
(1/1) downgrading lvm2                             [#########################] 100%
:: Running post-transaction hooks...
(1/6) Reloading system manager configuration...
(2/6) Reloading device manager configuration...
(3/6) Arming ConditionNeedsUpdate...
(4/6) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux510.preset: 'default'
  -> -k /boot/vmlinuz-5.10-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.10-x86_64.img
==> Starting build: 5.10.75-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [keyboard]
  -> Running build hook: [consolefont]
  -> Running build hook: [autodetect]
  -> Running build hook: [plymouth]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [plymouth-tpm2-totp]
  -> Running build hook: [tpm2]
  -> Running build hook: [plymouth-encrypt]
  -> Running build hook: [lvm2]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: /boot/initramfs-5.10-x86_64.img
==> Image generation successful
...

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…

if you are downgrading dont you have to downgrade “device-mapper” as well.