[Stable Update] 2022-08-07 - Kernels, Nvidia, Thunderbird, Cinnamon, Glibc, GCC, LibreOffice, Firefox, MangoHud, KDE-git

A post was split to a new topic: CommonIncludes.hpp exists in both libuinputplus and libevdevplus

After applying the update & rebooting I get a white screen saying "“uh oh, something went wrong, the system cant recover” :scream:
I do have a timeshift, but not sure how to revert if I cant boot. I do have a USB somewhere…

OK, managed to fix it :sweat_smile: booted to tty & ran full update again. it was already downloaded, but a bunch of things had been skipped. after a reboot back to normal.

2 Likes

Ah, nice. :expressionless:

Suspend is broken on my laptop again. This is like the third time an update did this (while staying on the LTS kernel 5.15.x series).

Something’s going on with upstream kernel development. I’ve experience three or four issues while on 5.15.x that break suspends and/or reboots.

What makes me resistant to troubleshoot this (again) is that the previous times all my troubleshooting efforts were in vain, since it was a matter of waiting for the regression to be fixed by the upstream kernel developers.

2 Likes

i have the weird scratching sound again. i had the same problem with the RC of kernel 5.19, so i went back to 5.17
it appears sometimes when i start a video/music/etc after i do not play any sounds for a while. i cannot even mute it. i scratches for a few sec and then its gone as long as sounds playing

i have an RX580 and i use HDMI for soundoutput

with kernel 5.19.0-2 the leds showing microphone and audio disabled not working
5.18 and 5.15 they hare fine for it

Since last Stable im still experience Firefox Coredumb errors.

1 Like

Yes, kernel 5.19 has the same problem as 5.18 with scratching sound sound on AMD Ellesmere HDMI Audio Radeon RX 590. Noise starting sound on AMD Ellesmere HDMI Audio Radeon RX 590.

Fortunately, kernel 5.15 does not have that problem.

1 Like

Can this glibc issue be added to the list of known issues in the Known issues and solutions? I am also affected by this issue and can’t play some games. I always look at this list of known issues for serious issues before updating.

@thingsiplay having EAC broken by a core package update is not critical for us as a distro. However, for those who are affected I’ve added the flatpak workaround and mentioned the patched glibc packages we don’t recommend to install officially.

having issue with wifi usb adapter TP-LINK TL-WN821N after this kernel update. In fact all my network devices disappeared after update and running inxi -N returns “No PCI device data found.” message.

edit
was able to get it working by installing rtl8192eu-git drivers package. Previously it was working on rtl8192eu package itself but its not a case anymore.

My update has no problem, but I suddenly got two orphaned packages:

intel-oneapi-mkl
onednn

Not sure what to do with them. I assigned them as explicit but don’t know where did they come from.

This update broke gcc/g++:

-- The CXX compiler identification is GNU 12.1.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:62 (message):
  The C++ compiler

    "/usr/bin/c++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/ave/Documents/oss/wors_tracer/build/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/ninja cmTC_6166d && [1/2] Building CXX object CMakeFiles/cmTC_6166d.dir/testCXXCompiler.cxx.o
    [2/2] Linking CXX executable cmTC_6166d
    FAILED: cmTC_6166d 
    : && /usr/bin/c++   CMakeFiles/cmTC_6166d.dir/testCXXCompiler.cxx.o -o cmTC_6166d   && :
    /usr/bin/ld: /usr/lib/libm.so.6: unknown type [0x13] section `.relr.dyn'
    /usr/bin/ld: skipping incompatible /usr/lib/libm.so.6 when searching for /usr/lib/libm.so.6
    /usr/bin/ld: cannot find /usr/lib/libm.so.6
    /usr/bin/ld: /usr/lib/libm.so.6: unknown type [0x13] section `.relr.dyn'
    /usr/bin/ld: skipping incompatible /usr/lib/libm.so.6 when searching for /usr/lib/libm.so.6
    /usr/bin/ld: /usr/lib/libmvec.so.1: unknown type [0x13] section `.relr.dyn'
    /usr/bin/ld: skipping incompatible /usr/lib/libmvec.so.1 when searching for /usr/lib/libmvec.so.1
    /usr/bin/ld: cannot find /usr/lib/libmvec.so.1
    /usr/bin/ld: /usr/lib/libmvec.so.1: unknown type [0x13] section `.relr.dyn'
    /usr/bin/ld: skipping incompatible /usr/lib/libmvec.so.1 when searching for /usr/lib/libmvec.so.1
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.

Or is the issue deeper than I can see?

❯ pacman -F /usr/lib/libm.so.6
usr/lib/libm.so.6 is owned by core/glibc 2.35-6

❯ pacman -Qi glibc
Name            : glibc
Version         : 2.36-1

So why is libm owned by an old glibc? Wasn’t it supposed to be upgraded?..

Anyways, downgrading gcc, gcc-libs, glibc and lib32-glibc, clang, llvm, llvm-libs helped. Please fix.

saddly that is right. tried 5.18 and it has the same sound problem.
i guess i go back to 5.15 and hope it does not have to much impact on gaming with proton

It’s not. -F is using own database, and you need to update it with -Fy. To query actual packages on your system you need to use -Q, in your case -Qo.

EDIT: Also you can edit the same post like I just did, and not post 10x one after another.

I always update with $ sudo pacman -Syuw . This only downloads and checks all packages without installing them, which I then later do from the tty.

Two packages, python-pivy and freecad, were marked as ‘marginal trust’ or corrupted, and thus asked to be removed, which I did. Re-downloading those two packages had the same result.

I tried to ‘fix’ the key problem by the old method of downloading archlinux-keyring and manjaro-keyring, and then $ sudo pacman-key --init , --populate, --refresh-keys but the latter step produced very many errors and possibly further corrupted my key database.

I then turned to the Manjaro wiki and also found the old method there but it is now scratched out. Luckily there is now a new method which worked to get my key database re-established.

The two problem packages were downloaded and checked without problems and I could proceed to tty $ sudo pacman -Su for a successful update.

1 Like

After this update & applying k 5.19 my suspend sticks on black screen when waking.
Using 5.18 it works ok.

Since k 5.11 iommu=soft has been flawless for suspend working on my AMD. But 5.19 has broken something anew.

2 Likes

I’m having issues with passing GPU to virtual machine
After the update calling nodedev-detach results in a crash in amdgpu_device_fini it was working before
As a workaround binding using vfio-pci.ids works (as long as you have second GPU ofc)

My card is Radeon RX 6800 XT

Same here: Firefox Coredump errors in journal
@bogdancovaciu posted about it HERE
Got rid of the Coredump errors by removing the libva-vdpau-driver.
Works for me as well.
At least a temporary workaround…

Yes, reported this as well, at this time I see no fixups here:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.19

You can also bisect bad and good Kernel version to identify which commit causes this problem.

And it’s a good choice to use LTS Kernel.:
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Suspend/hibernate_does_not_work,_or_does_not_work_consistently

Suspend/hibernate does not work, or does not work consistently
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.

2 Likes

My guess it was something they did on 5.19 that was backported to 5.15 as well. That’s what happened last time with suspend and 5.17 which was backported to 5.15.


I already do. My whole reasoning for sticking with only “LTS” kernels was to avoid these types of nasty bugs. As you can see, it also affects me on 5.15.59, so I think the regression was backported. :frowning:

Nice find, I’ll take a read through it. I’m just tired of these frequent show-stopping bugs from the upstream kernels lately. Especially when they affect “LTS” kernels. When suspend is broken on a laptop, it’s a major issue. (This has happened before two previous times with an update to 5.15.x, one broke suspend, the other broken reboot/shutdown.)

EDIT: The last time an upstream kernel update broke suspend, a bunch of Arch Linux laptop users really felt it. So probably going to keep an eye peeled on the Arch Linux BBS.

1 Like