In my case I still have the isue with grub (…press any key). I tried a solution posted but that did not work for me. In fact I did a fresh install a few days ago and made the update. So today I made this update (april 6) and it worked well.
There are multiple things which can cause that issue. cryptsetup package had changes for systemd 253. However we still ship 252, which doesn’t have that. Hence I reverted those changes on the cryptsetup package to match our systemd series. So yes, apply the update and see if that magically solves your issue. Take part at the discussion we have about that topic and report back your finding: Can't boot LUKS encrypted install after 2023-03-31 stable update
If someone can still boot, we call it a nag screen. Since we don’t know what the actual issue is, those community suggestions helped some of our users. As soon as there is a solution or guideline we will update the information. So far it is partly guessing. You can read my take on it to have more info about it.
I’m also getting this not such cryptodisk found line (but booting with no problem for now). In my case is most probably triggered for I’m keeping the systemd 251 till 252 is out (I don’t want to loose the timed suspend-then-hibernate option that was removed with 252, and is planned again for 253). So, I guess that 252 is coming not much later, and I can live with that for now.
Just, I saw the information about not using dashes for the UUID for LUKS devices in grub… Should then everyone change that line yet, wait if it’s working (with just the line showed), or what is the recommended procedure? Perhaps just try to modify the line directly in grub when booting, to check if it makes any difference, before changing anything permanently?
EDIT: after trying changing manually from grub menu to confirm it works properly, just taking out (manually) the dashes from the cryptomount -u lines in /boot/grub/grub.config , as suggested, avoids the (no so) annoying prompt. So, by now it’s an easy solution, to be applied whenever grub is updated; and probably future upgrades will solve it completely. Thanks again!
After this update, it might have even been the 23.03.31 one, Gwenview hangs when playing an .mp4 file and after it finishes, you go to the next item, be that a pic or vid. You see the little wheel spinning in the center and can not but force the application quit.
There is no such bug when the video is still playing or when you move backwards. Also, changing to the Browse overview in Gwenview once the video has finished playing hangs the application.
There was a similar bug some years ago, fixed without confirmation, which might have been Qt related: show_bug.cgi?id=344809
The bug didn’t exist before the 2 most recent update cycles.
Reinstalling Gwenview, rebooting, to no avail.
I am running a Ivy Bridge CPU and KDE Wayland. I saw the comment about adding LIBVA_DRI3_DISABLE=1 to /etc/environment, actually added it with a “#” in front so it would be inactive but I wouldn’t have to re-research when I forgot about it.
Are there any other ill effects to the overall system by adding that variable? To me, it sounded like a drastic change to make to re-enable HW acceleration for Chromium where maybe just a bit of patience would make it work again. I mostly use Firefox anyhow.
AFAIK this fix is intended for X11 and not wayland. from the little i do know this is due to libva-intel-driver not supporting DRI3 for pre-haswell iGPUs, and thus breaking functionality since libva 2.17. on X11 it is not as much of drastic change to get things going because it is afterall due to un-supported functionality of the intel driver. i’m afraid waiting will do no good, libva-intel-driver dev team is supposedly very inactive and since we are talking legacy HW here chances of them supporting DRI3 is very slim.
After locking pc and unlocking it after a couple of hours, either secondary or both screens are black. KDE plasma seems like its dead. No taskbar, background, right click does nothing. Reboot fixes it, but this is annoying. Any ideas what I could do? Before the 30.3.2023 update it never occurred. Now it occurs daily.
Found an old issue, similar to this found here. Mine is the same, but occurs sometimes when I lock and unlock pc. Never on restart. At least not yet.
Nvidia high refresh being unable to be set and the monitor generally feeling like it’s burning my eyes is still an instant issue (like it was last update) after applying previous update and then this update over it.
Rolling the system back again, not even trying another update till there’s a really good reason to believe that I can update without experiencing eye pain pretty much instantly.
Yubico Authenticator doesn’t show the codes, again . The same problem was in November 2022.
Downgrade yubikey-manager to 14.09.-3 and is works fine.
Obviously update of yubikey-manager took place in previous system update.
This update breaks the inclusion of .eps pictures when using xelatex in TeXLive (texlive-core 2023.66587-1), which is a pretty critical bug as it completely prevents compilation of affected TeX documents. The problem seems to be inherited from Arch (see Arch bug FS#78098 - [texlive-core] /usr/bin/rungs links to a non-existing file). In the Arch repos, it is already fixed in texlive-core 2023.66587-2, so hopefully this package version can be included in Manjaro soon.