I’m suffering the same symptoms since the last stable update. Maybe it’s this problem with MESA and Radeon Vega Graphics… I just downgraded to v24.2.8.
I can see how you might think so, however, note this comment from the link you referenced;
and according to their inxi output the OP is not using Wayland;
I’m seeing several similar forum threads about random crashing, and several more in the wild. Perhaps they all share a common root cause, given the sudden frequency of reports; or perhaps not. 
I dare say it’s difficult to pinpoint without reliable reporting in sufficient numbers, but something is surely afoot.
2 Likes
I see it exactly the same way. In these cases it is all the more important to insist on “inxi -zv8”. Only then is it possible to work out the commonality at a certain point.
I think that in this case it is also helpful to use a new tag to connect all these contributions (if inxi is available)
Done
I found 16 threads from the last 30 days that talk about freezes/reboots. Some seem to be resolved, but most are not. The descriptions differ, but that may simply be because individual users have different perspectives. The frequency varies from “every 30 minutes” to “once a week”. I have tagged all of these threads with a common tag “random_crash”.
2 Likes
Well, I had to do some trickery to get logs to survive from the crash at all, since it seems to be a CPU issue and so sudden it makes journalctl’s logs irrecoverable, so if they’re having the same issue I’m not surprised they lack information.
I should note that the trickery in question was running
#!/usr/bin/sh
time=$(date +%s)
mkdir -p ~/logs/$time
dmesg -w >~/logs/$time/dmesg.txt &
journalctl --follow >~/logs/$time/jctl.txt &
on boot, together with adding kernel.dmesg_restrict = 0 to /etc/sysctl.d/99-custom.conf. That made sure anything passing through dmesg or journalctl survived the crash.
Or it should. Yesterday I ran into something new that may or may not be related, the crash made krita’s timelapse recorder (Which just saves a string of jpegs) save several 0 byte files, having 200 gb of space available. So either it messes up R/W or some component goes and locks the disk when it notices the cpu messing up. Will report if I see it happen again.
Also last note: Ran with Cinnamon to check if it was plasma, and also had the crash there. So it’s a general issue, not plasma specifically.
1 Like
Did the same and, well, I’d recomment against it. Blackscreened my system and had to boot in text mode to get it back up to date.
Yep can confirm, it’s twice now.
The non-empty file was from opening it after the crash. But what I get rom this that may actually be useful is it gives me a specific time when the crash started and the system entered a dead man walking status, and how long it took to become noticeable.
Have you tried using Wayland to see if these crashes might only be related to X11? That would surely be useful to know.
Plasma on wayland doesn’t yet support wacom in relative mode, which I use for work stuff. If I have an excuse to leave the computer idling for a few hours with some benchmark to make crashes more likely I will, but I wouldn’t hold my breath on that.
Sorry to hear. Unfortunately my downgrade didn’t fix the issue. But I installed v25 from the very same thread and I haven’t had a freeze ever since. fingerscrossed
BTW I’m running on X11, too.
You mean you did a clean install from here [Stable Update] 2025-02-04 - Kernels, KDE, XFCE, Mesa, Cosmic, Systemd or you did an install of the previous iso release? I haven’t done the later yet because I don’t want mixed packages.
In case you did a clean install of the new version, does manjaro behave like ubuntu in that the installer just leaves your home dir alone or do I need to back it up.
I’m not sure what you mean by “mixed packages”; if the system is up to date, you’ll end up with the same versions (depending on branch, of course).
In the case of a manual installation: if you select not to format the /home partition, stuff may get added to it but your existing data and configurations should be safe. Best to back it up anyway, though.
Having an older version that I’m not doing a full update of but I’m still installing new packages, which brings new packages at current versions and incidentally update some packages alongthe way. Sounds like the closest modern linux can get to windows 95 esque dll hell through casual use.
Not doing a full system update but still adding packages is never a good idea with a rolling-release OS such as Manjaro or Arch. it leaves your system in an unsupported state and will very likely cause issues like crashes.
If you do sudo pacman -Syu and tend to your .pacnew files, then after this, update any AUR packages you may have, you should be OK.
A recommended way to install new packages is:
sudo pacman -Syu <packagename>
I was refering to the MESA v25 fixed build from this thread.
Off topic;
Linux has a long tradition of dependency Hell, which seems generally less of an issue in these times; but that’s nothing like M$ .dll legacy of non-related functionality crammed into random libraries.
I think we could easily add a few Linux-esque Hell’s if we were to make a list; this one would likely rank fairly high:
- the AUR and new starry-eyed users Hell
Perhaps a little cynical; everyone has to start somewhere, I suppose, but it can often be a serious Hell for those trying to help.
Oh, that looks like it’s progressing nicely and the issues match my cpu, hopefully they round out the fix and manjaro gets it soon.
Changed to mesa-devel (It was buried in that arch thread) yesterday and haven’t had any crashes since, seems like it worked.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
So is it actually advisable to do this update? It has new mesa which might let me drop the -git version, but I’m seeing a lot of display driver issues.