Raptor Computing Systems Community Forums (BETA)
Software => Operating Systems and Porting => Topic started by: tle on April 23, 2024, 09:29:08 am
-
More info: https://fedoramagazine.org/announcing-fedora-linux-40/
The F40 brings GNOME 46 and Linux kernel 6.8.7. Chromium RPM package is officially supported.
IMHO it is probably the best version for my blackbird till date. All sluggish gfx regression of mutter is gone, everything runs pretty snappy.
amdgpu works out of the box (well the only thing that does not work is no HDMI signal which does not impact me much as I am using DisplayPort)
There are a bit bugs with certain apps for example GNOME Loupe could not open image file.
-
Great news, unfortunately the 6.8.x series kernels perform poorly with SSD, below average from the last two years ;)
-
Great news, unfortunately the 6.8.x series kernels perform poorly with SSD, below average from the last two years ;)
Just curious to know if 6.9 would address this issue
-
What worries me most is the very large variance in SSD performance from version to version. Once it is 4.5 GB/s and the next time it can be even less than 1 GB/s. The best was in versions 6.2.x, there the SSD reading speed often exceeded 6 GB/s.
BTW.Does a machine reboot work properly in Fedora 40? With me on Fedora 39 since kernel 6.6.x, the system crashes after reboot, turns the fans on to the max and I have no video signal on the HDMI of the embedded card. I have to turn off Talos II from the Power button and turn it on again.
-
Well then we can update without problems, it's nice to recover Chromium after years and that the system has finally stabilized regarding the general performance of GNOME. The initial bugs on Fedora are nothing new, we know that we have to act as a test bed since it updates very quickly, I'm not worried about this in fact, they will fix it soon as usual.
-
the system crashes after reboot, turns the fans on to the max and I have no video signal on the HDMI of the embedded card.
Is fast reboot on or off?
-
I also updated to version 40 and I confirm what my TLE friend said, everything works well on Fedora 40, they have finally made Gnome's performance stable and it's about time I would say. I installed Chromium, I also found the favorites I had on version 87 which were obviously removed because there was no longer support as we all know. Except unfortunately I'm noticing that it has some bugs to fix unfortunately at the moment. I don't know if you too have had the opportunity to try Chromium but at least for me it crashes after a few minutes of use, at a certain point the browser freezes the hard disk starts loading who knows what and then Chromium closes at sudden. Fedora also detects an error on a component and obviously reports it automatically, so the first reports of malfunctions relating to Chromium on Fedora have already started. However, it's great that he's officially back on Fedora, that's what was needed too. Let's wait for them to start solving the first problems now.
-
Is fast reboot on or off?
I have "Auto boot -> Disabled" in the Petitboot configuration, but I haven't changed that since I started using Talos.
I guess it shouldn't make a difference since rebooting worked fine on older kernels?
-
Auto boot and fast reboot are two different things and old kernels don't have the same bugs as new kernels.
-
Auto boot and fast reboot are two different things and old kernels don't have the same bugs as new kernels.
Exactly. See https://shenki.github.io/skiboot-disable-fast-reboot/
-
In my system:
[root@talos2 ~]# nvram -v -p ibm,skiboot --print-config
NVRAM size 589824 bytes
NVRAM contains 4 partitions
"ibm,skiboot" Partition
--------------------------
-
Joy of joys - in setting up my clean install of Fedora 39 I did some media repo poking, opting for Red Hat’s non-free sources so I could get video acceleration properly working in YouTube and VLC. But when I try to run the Fedora 40 upgrade it kvetches that it can’t find corresponding packages and throws the brakes on things. Should I run it with —allow-erasing and prepare to redo my repo selection on the other side?
-
Joy of joys - in setting up my clean install of Fedora 39 I did some media repo poking, opting for Red Hat’s non-free sources so I could get video acceleration properly working in YouTube and VLC. But when I try to run the Fedora 40 upgrade it kvetches that it can’t find corresponding packages and throws the brakes on things. Should I run it with —allow-erasing and prepare to redo my repo selection on the other side?
Could you be more specific which non-free repo sources? I am using RPMFusion for non-free codec and Mesa and have no issues at all.
-
Disregard - decided I must have followed a bad post-setup guide for F39 that broke something in the installer, so I went ahead and performed a clean install while maintaining my /home partition’s contents. Reporting in, it’s… working fine? Apart from Chromium, which is behaving as others have mentioned: it’s quick initially but bogs down and seems to stare into space in fits and starts before finally locking up and crashing. Sharkcz’s copr of Firefox 115.10 with the honorable ClassicHasClass’s JIT patches to the rescue.
-
And now, after updating and rebooting, the default Image Viewer fails to load an image, citing
(https://i.postimg.cc/nzHfJM6c/Screenshot-2024-05-07-19-51-22.png)
This also causes SELinux to catch three errors:
1. Source process systemd-coredump attempted access sys_admin on capability (blank)
2. Source process abrt-dump-journal attempted access connectto on unix_stream_socket io.systemd.Home
3. Source process abrt-dump-journal attempted access connectto on unix_stream_socket io.systemd.Machine
Ristretto works and I'm running Xfce anyway, but what the hell.
-
I have reported that error.
I also pick up few other errors with applications such as dosbox-staging.
The common issue is that apps that are built with vendored Fedoran libs
are likely to misbehave. This is one of many reasons why few packages
have to resolve to use the bundled libs that the app come with.
-
What was the issue with dosbox-staging? Something I should look at or do you think it's packaging-specific?
-
What was the issue with dosbox-staging? Something I should look at or do you think it's packaging-specific?
I got segfault when trying to run Master of Orion II
ref: https://bugzilla.redhat.com/show_bug.cgi?id=2276363
-
Yeah, something was borked with the default DOSbox-Staging on F40. I installed the suggested --advisory=FEDORA-2024-b6cc2aa248` and that mitigated my issues, though I did have DOSBox hard lock once while running Redneck Rampage with a VESA mode enabled afterward. Fortunately the Rednukem source port compiled and ran effortlessly on the hardware. I'll try out other DOS games as free time becomes available... to test the stability, of course.
-
That version should have my fix in it, so it must be something else.
-
I'm not worried, Redneck Rampage was always flaky and in hours since it hasn't so much as burbled - which means DOSBox-Staging is at least as stable as any actual DOS machine I ever ran.
Incidentally, I did a performance comparison of DOSBox-Staging between my three machines by running Quake in 320x200, and both my M2 Air and Ryzen 5700GE notch over 200 fps, while the Power9 wrangles about 35. I want to be clear that I'm not complaining: the Power9 is delivering performance that feels very much like a midrange Pentium, which means it's sufficient for anything that all but crazy people would ask of MS-DOS, but I am curious about the sheer amount of that difference.
-
I'm not sure, actually. I'll have to load it up on my M1 Air and check it out. The x86_64 figure could be because those don't use dynrec, but ARM should ... unless you're running the Intel Mac build on your M2, not an Apple silicon build?
-
I'm not sure, actually. I'll have to load it up on my M1 Air and check it out. The x86_64 figure could be because those don't use dynrec, but ARM should ... unless you're running the Intel Mac build on your M2, not an Apple silicon build?
You're right - I figured the Ryzen was largely running native code. To the point on Apple Silicon, the DOSBox Staging build I snagged indicated it was a Universal Binary for Apple Silicon and Intel, but I wonder if it it's running an Intel-native binary and doing an end run around dynrec. Let me know what you find on the M1.
-
Is Rosetta checked in Get Info?
-
It was not. Doing a comparison with Rosetta enabled versus ARM-native yielded this result:
Running timedemo demo1 for DOS Quake v1.07 at 320x200 in DOSBox-Staging:
Rosetta: 80.5 fps
Native: 145.0 fps
I don't know why I thought the Air pulled 200+ fps earlier, but 145 fps is easily high-end Pentium III territory regardless.
-
That gives me some point of comparison, though it may be difficult to figure out what specifically the ARM dynrec is benefiting from. But thanks for looking at it.