Hey, I tried installing The Fedora Workstation 40 Beta on my laptop and It gets installed fine, but some programs crash when I run them (node, npm, mediawriter, prismlauncher). I also noticed that on boot a notification comes up that gstreamer1 or something like that crashed.
What I did to try to fix: installed the beta from the server netinst, the Live ISO and the F39 Live iso (working here in F39) and then upgraded with dnf.
After some thinking I remembered there was some proposal to provide optimized x86_64_vx binaries (Changes/Optimized Binaries for the AMD64 Architecture - Fedora Project Wiki). There is a line where the following is stated: When code is compiled for a higher microarchitecture level it will crash (with SIGILL, "illegal instruction") on CPUs which do not support it.
But the proposal was denied so This isn’t the problem. Have there maybe been changes to build arguments between between the two versions?
While I cannot answer your question, I cannot help but notice a dicotomy in your question and the title.
The title mentions zsh and the tags show#server.
The server release uses xfs file system.
Workstation uses btrfs file system for both f39 & f40.
We really need more info and to work with only one installed OS since when you bounce between versions there is no clarity as to the exact configuration and no starting point to plan a path to a solution.
Install a single version of the system, update it to the latest software versions, tell us what it is, then stay on that version while we work to identify and provide potential fixes for the problems you see at that point. If you intend to work with a gui desktop it is best that you avoid the server version since you would have to manually install and configure the gui on server.
Yes I am on the Fedora 40 Beta, updated with dnf upgrade --refresh.
There are several apps crashing, i.e.: node or mediawriter. I also noticed that on boot a program called gstreamer1 crashes. All of these crash with Illegal instruction (core dumped) when running from terminal.
I just tested mediawriter from the command line on my f40 test bed. It provided a lot of messages when launched from a terminal but did not crash. node apparently comes from the nodejs package and I do not have it installed.
Gstreamer1 should not be launching automatically at boot so the way you stated that is surprising to me.
Please first run sudo dnf distro-sync to ensure everything is fully in sync with the repo then provide the text from trying to run each of those commands from the terminal window by copy & paste using the preformatted text tags done like this
```
paste the text here
```
From a terminal window those commands will normally give much more info than when launching from the desktop icon.
It may take a lot more info to identify the problem, and also might benefit us all if you were to provide details of your system using inxi -Fzxx. Even a bug report requires much more info and a crash usually provides a crash dump for tracing the cause.
If you installed xz version 5.6.0 from rawhide and downgraded per Urgent Security Alert, crashes could be indicators of compromise.
Crashes in multiple programs often come from a common shared library. You can see the list of libraries loaded by each program using ldd. Compare the list for programs that work with the list for programs that crash to see if there is one library common to the crashes. If you identify the responsible package you can examine the .spec file to see what compiler flags were used.
The ABRT Analytics - Report #913065 - nodejs20 in simdutf::internal::unsupported_implementation::unsupported_implementation... case is similar. The nodejs20 tarball contains a bundled project named simdutf. For this one, file a bug against nodejs20 and point out that deps/simdutf/simdutf.h does check cpuid, but still wants at least one of pclmulqdq, SSE 4.2, osxsave, bmi1, bmi2, avx2, or one of the avx512 variants, none of which are guaranteed to be available on the x86_64 CPUs supported by Fedora.
You aren’t the victim of any kind of concerted effort to make your CPU not work. This is just various uncoordinated upstreams assuming they can move on from the original x86_64 and the Fedora packagers failing to notice.
Okay. That code also uses various vector instructions. I didn’t bother tracking down which instruction sets they were from. (Some, at least, are SSE2 which is present on all x86_64 CPUs.) Out of curiosity, what does “cat /proc/cpuinfo” show?
Huh. Well, that means pretty much everything I told you is wrong. Your CPU does have support for SSE 4.2, for example. Something else is going on here, but I’m afraid I don’t know what.