Fixed in our overlay package. Will be fixed with 4.16.1 release of Thunar.
2 Likes
Confirmed that it is fixed with thunar-4.16.0-1.1-x86_64.pkg.tar.zst .
I just switched from Testing to Unstable, I had 147 packages to update.
Only one signature problem with gnome-session.
I uninstalled gnome-session, did the updates, then I reinstalled it and NetworkManager since it had uninstalled it from me.
I rebooted and no more problems.
pacman-key --refresh-keys
Would be the easier and less hustle way 
1 Like
Oops. Fixed with 3.38.0+14+g87d92fec-1.0.
Actually it wouldn’t make any difference in this case. The keys were valid, it was a conflict between the signature registered in our repos with our overlay package vs. the original Arch package.
Again, fixed. Nothing to see here, move along. 
1 Like
Does anyone else experience issues booting 5.11-rc1 with i915 graphics? X doesn’t start on my machine, SDDM won’t show up, switching to TTY is failing too.
Don’t know about i915, but 5.11-rc1 is working great on nvidia here.
It’s very nice of the team to add the nvidia drivers to the rc so early this time.
Just the error message on boot (same we had a couple weeks ago on 5.10) : “failed to load valid kernel BTF”.
Other than this single thing, everyhing is working great.
1 Like
Actually I ran into some issues just recently trying to mount some backup truecrypt files. There is a solution here about setting up a loop device before attempting to mount a file, but it will automount the loop devices if you first attempt to mount and the thing chews on it for a couple minutes and then finally spits out a loop error message. Just trying again does then work. Probably time to migrate to veracrypt but I can’t be bothered right now.
OK I’ve narrowed down a list of possible culprits, now it’s clear to me that this is caused by an extra monitor connected to an HDMI port. Still not sure what the exact reason is and gosh I don’t want to go through one more bisect this year 
Hope there would be someone more motivated than me 
Jo, funktioniert. (5.11.rc1.d1229.g139711f-1)
I found a very weird bug in xfce’s mousepad 0.5.1 – if you do a ctrl+f to find a word, and then paste something into the search box (using ctrl+v, not right-clicking and selecting paste), the pasted word will be actually placed wherever the cursor is in the actual document. I checked Libreoffice and it’s unaffected.
Did I miss something about force-install of linux54 and linux510 ?
Only if you run EOL kernels: manjaro-update-system.sh · 38c52d68a7c26307b15847bec937b3987909b3f3 · Packages / Core / manjaro-system · GitLab
But I dont. I had a perfectly fine 4.19-manjaro installed, and was running a custom 5.4-raven … now I also have 5.4-manjaro and 5.10-manjaro aswell …
Before:
$ mhwd-kernel -li
Currently running: 5.4.85-RAVEN (linux54)
The following kernels are installed in your system:
* linux419
After:
$ mhwd-kernel -li
Currently running: 5.4.85-RAVEN (linux54)
The following kernels are installed in your system:
* linux419
* linux510
* linux54
(note: mhwd doesnt recognize the 5.4-raven besides reporting it as currently running)
maybe you updated to fast. see changelog: Commits · master · Packages / Core / manjaro-system · GitLab
haha my timing is nutz. so maybe so.
not hard to remove them anyways.
Ill chirp about it again if it keeps popping up.
I’m having the same since the update to 5.10.4-1, clearly there’s something wrong with patches backported from 5.11 tree.
Side Note: VM Environment: sudo mhwd-kernel -r linuxXY doesn’t uninstall Kernels correctly. Need to remove remaining Kernel files in /boot/ manually.
It’s fine on stable sudo mhwd-kernel -r linuxXY does what it is supposed to do
OK, here is the solution to the problem I reported a couple of days ago.
Commits db71bc7ef3edd98299f83c7dba80b2cdba32de23 (5.10.4) and b1a5039759cb7bfcb2157f28604dbda0bca58598 (mainline) introduced this regression.
Bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=210983
Patch: [PATCH] ALSA: hda/hdmi: Fix incorrect mutex unlock in silent_stream_disable()
I named it 0201-ALSA-hda-hdmi-Fix-incorrect-mutex-unlock-in-silent-stream-disable.patch
0201-ALSA-hda-hdmi-Fix-incorrect-mutex-unlock-in-silent-stream-disable.patch
The silent_stream_disable() function introduced by the commit
b1a5039759cb (“ALSA: hda/hdmi: fix silent stream for first playback to
DP”) takes the per_pin->lock mutex, but it unlocks the wrong one,
spec->pcm_lock, which causes a deadlock. This patch corrects it.
Fixes: b1a5039759cb (“ALSA: hda/hdmi: fix silent stream for first playback to DP”)
Reported-by: Jan Alexander Steffens (heftig)
Cc:
Signed-off-by: Takashi Iwai
sound/pci/hda/patch_hdmi.c | 2 ±
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 1e4a4b83fbf6…74d246a0dc6d 100644
— a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1733,7 +1733,7 @@ static void silent_stream_disable(struct hda_codec *codec,
per_pin->silent_stream = false;
unlock_out:
- mutex_unlock(&spec->pcm_lock);
- mutex_unlock(&per_pin->lock);
}
/* update ELD and jack state via audio component */
2.26.2
Turned out it was already reported but I couldn’t find it until I bisected 5.11 in search of a culprit.
Tested both 5.11-rc1 and 5.10.4, the issue is resolved.
I guess I have no access to MJ Gitlab to make a PR, hence I post it here. Pinging @nightmare-2021
As it was reported by an Arch maintainer, I guess Arch will have it included soon (or already has it, I didn’t check).
1 Like
Thanks for the information.
The patch (fix) will be adopted in build 5.10.4-3 and will be available on unstable shortly.
For the 5.11 it’s included with the rc2.
2 Likes