Raptor Computing Systems Community Forums (BETA)
Software => Operating Systems and Porting => Topic started by: tle on November 15, 2022, 05:17:15 pm
-
Source: https://fedoramagazine.org/announcing-fedora-37/
To me it is a great release because many annoying issues such as stuttering graphic performance with mutter is gone. Plus many packages are now more up-to-date which really helps with getting amdgpu driver running for RDNA2-based GPU.
Having said that it sucks to know that Fedora no longer enable hardware decoding for Mesa (http://www.phoronix.com/news/Fedora-Disable-Bad-VA-API), I have to manually revert the patch to compile my custom RPMs.
-
Another review from our beloved member https://www.talospace.com/2022/11/fedora-37.html
-
Folks, if you want to revert the codec mesa change, here how you could do it
fedpkg clone -a mesa
cd mesa
git checkout origin/f37
git revert 94ef544
sudo dnf builddep mesa.spec
fedpkg local
If you use ffmpeg, please also re-compile to support HEVC/H.265 code:
# Install RPMFusion Free Repo first
sudo dnf install x265
fedpkg clone -a ffmpeg
cd ffmpeg
git checkout origin/f37
sudo dnf builddep ffmpeg.spec
fedpkg local --with x265
Alternatively, the better way is to use RPMFusion:
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
-
Or you can use mesa-freeworld from RPM Fusion. It should complement the reduced mesa from Fedora.
-
Why was hardware decoding removed as default, compatibility reasons?
-
It is because of licensing. Anything that might pose legal issue to the project is likely being removed
-
How can I ensure my latest installed kernel runs? I’ve installed updates through kernel 6.0.12, but it’s still booting to 6.0.7 with no other versions showing at the petitboot selection. I used grubby as a walkthrough dictated to change the default kernel but that doesn’t seem to have persuaded petitboot to play ball… and I don’t want hassles whenever they push through kernel 6.1. To say I’m eager to pair the Radeon RX 6600 I picked up with my Power9 is an understatement.
-
What I can tell you about Fedora is that unlike Debian and derivatives, you can't download the Kernel from the classic source and compile it because it necessarily requires its procedure and it necessarily wants its sources. You must therefore necessarily download from Fedora sources and use their specific procedure. One of the reasons that prompted me not to use Fedora anymore is precisely this, which represents a limitation for me. In their sources you can only download the version they say and you can't even use the universal procedure because at a certain point it doesn't work anymore.
-
I understand that’s an issue, but it isn’t the one I’m running into. dnf has installed multiple kernels, and grubby enumerates them, but only 6.0.7 is enumerated in petitboot, and using grubby to set it to the newest 6.0.12 does nothing. What procedure do I need to follow to get Fedora to enumerate my installed kernels in petitboot?
-
In order for petitboot to see the new kernels you must run the following commands after the update:
$ sudo grub2-mkconfig > /boot/grub2/grub.cfg
This situation is due to an error in the /usr/lib/kernel.d/99-grub-mkconfig.install script on lines 28 and 29.
The script expects the Pettitboot version in Num1.Num2.Num3 format and reads the values in CRC1-CRC2 format.
-
What DKnoto said. Same thing bites me on every update. Oddly, though, only on the T2 -- the Blackbird doesn't seem affected.
-
This script gets the Petitboot version number from a file like this:
cat /sys/firmware/devicetree/base/ibm,firmware-versions/petitboot
and expects this string to be of the form, for example, 1.8.0 and gets something like this:
cat /sys/firmware/devicetree/base/ibm,firmware-versions/petitboot
0ed84c0-p94177c1
-
Right, that's this bug, reported by yours truly: https://bugzilla.stage.redhat.com/show_bug.cgi?id=1921479
It should be fixed, but on the T2 at least, it doesn't seem to be.
-
In order for petitboot to see the new kernels you must run the following commands after the update:
$ sudo grub2-mkconfig > /boot/grub2/grub.cfg
This situation is due to an error in the /usr/lib/kernel.d/99-grub-mkconfig.install script on lines 28 and 29.
The script expects the Pettitboot version in Num1.Num2.Num3 format and reads the values in CRC1-CRC2 format.
This worked a treat, thank you! Once I'm done with some holiday traveling, I will start writing down some of what I've learned in getting Fedora to go my way. Periodically it wants to take several minutes to shut down, and I haven't had any luck looking at console output to see what's making it spin its wheels... but if that's the only wrinkle I run into, I think I'm okay with it.
-
And actually it did it on the Blackbird today when I tried to update it. So I think something regressed.
-
And actually it did it on the Blackbird today when I tried to update it. So I think something regressed.
That’s oddly reassuring, in a way. Glad the regression isn’t somehow isolated to my machine.
-
Another great review from our fellow member
https://www.talospace.com/2022/12/fedora-37-mini-review-on-blackbird-and.html?m=1
-
On balance, what’s the most hassle-free way to install a 6.1 kernel to Fedora on Power9? I’ll accept steps to manually compile it, but am hoping to test my Radeon RX 6600 soon and it seems like every week we get another kernel 6.0.xx release.
-
Probably compile from the Fedora package itself: https://fedoraproject.org/wiki/Building_a_custom_kernel
I haven't done this recently, but I used to do it when I was hacking on KVM more.
-
On balance, what’s the most hassle-free way to install a 6.1 kernel to Fedora on Power9? I’ll accept steps to manually compile it, but am hoping to test my Radeon RX 6600 soon and it seems like every week we get another kernel 6.0.xx release.
FYI https://fedoramagazine.org/contribute-at-the-fedora-linux-test-week-for-kernel-6-1/
-
The 6.1.0.x is now available on the main F37 dnf tree
-
My Fedora install has developed a wrinkle in the past couple of days. On running sudo dnf update, I receive the following message:
Last metadata expiration check: 1:23:53 ago on Fri 10 Mar 2023 06:02:42 PM CST.
Dependencies resolved.
Problem: The operation would result in removing the following protected packages: systemd, systemd-udev
====================================================================================================
Package Architecture Version Repository Size
====================================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
systemd ppc64le 251.7-611.fc37 fedora 4.3 M
systemd ppc64le 251.13-5.fc37 updates 4.3 M
systemd-libs ppc64le 251.7-611.fc37 fedora 652 k
systemd-libs ppc64le 251.13-5.fc37 updates 652 k
systemd-pam ppc64le 251.7-611.fc37 fedora 355 k
systemd-pam ppc64le 251.13-5.fc37 updates 354 k
systemd-rpm-macros noarch 251.7-611.fc37 fedora 30 k
systemd-rpm-macros noarch 251.13-5.fc37 updates 29 k
Skipping packages with broken dependencies:
systemd-container ppc64le 251.13-5.fc37 updates 556 k
systemd-devel ppc64le 251.13-5.fc37 updates 578 k
systemd-networkd ppc64le 251.13-5.fc37 updates 614 k
systemd-oomd-defaults noarch 251.13-5.fc37 updates 25 k
systemd-resolved ppc64le 251.13-5.fc37 updates 284 k
systemd-udev ppc64le 251.13-5.fc37 updates 1.9 M
systemd-udev ppc64le 251.7-611.fc37 fedora 1.9 M
Transaction Summary
====================================================================================================
Skip 15 Packages
Packages unrelated to these install fine, but these are invariant and inflexible in failing to install. It appears that somehow I've entered dependency hell, as attempting to run sudo dnf update -- results in this:
Error:
Problem: The operation would result in removing the following protected packages: gnome-shell, grub2-ppc64le, systemd-udev
It suggests using --skip-broken to skip uninstallable packages, but that makes no difference. I don't think I did anything novel, so maybe something scabby got pushed in a package that's throwing things off. Any suggestions? I can probably limp this along as-is until the April-ish release of Fedora 38...
Edit: manually installing systemd-251.7 went without a hitch. The changelog for 251.13-5 indicates some dependencies were changed to prevent an edge case, but I’m guessing it’s causing other issues as well. So it’s likely that I can just wait a few days and this problem will go away by itself.
-
I have had the same problem for a few days and came to the same conclusion, I am waiting ;)
-
I finally found some time to fix the /usr/lib/kernel/install.d/99-grub-mkconfig.install script.
A bug in this script caused that after updating the kernel petitboot did not see the new kernel
and I had to do the kernel list update manually:
# grub2-mkconfig > /boot/grub2/grub.cfg
The problem is caused by this piece of script, lines 22-34:
if test -e ${petitboot_path}; then
read -r -d '' petitboot_version < ${petitboot_path}
petitboot_version="$(echo ${petitboot_version//v})"
major_version="$(echo ${petitboot_version} | cut -d . -f1)"
minor_version="$(echo ${petitboot_version} | cut -d . -f2)"
if test -z ${petitboot_version} || test ${major_version} -lt 1 || \
test ${major_version} -eq 1 -a ${minor_version} -lt 8; then
RUN_MKCONFIG=true
fi
else
RUN_MKCONFIG=true
fi
After the change to:
if test -e ${petitboot_path}; then
read -r -d '' petitboot_version < ${petitboot_path}
petitboot_version="$(echo ${petitboot_version//v})"
if test ${petitboot_version} = "0ed84c0-p94177c1"; then #
RUN_MKCONFIG=true # My Talos II petitboot version
else #
major_version="$(echo ${petitboot_version} | cut -d . -f1)"
minor_version="$(echo ${petitboot_version} | cut -d . -f2)"
if test -z ${petitboot_version} || \
test ${major_version} -lt 1 || \
test ${major_version} -eq 1 -a ${minor_version} -lt 8; then
RUN_MKCONFIG=true
fi
fi
else
RUN_MKCONFIG=true
fi
The script started working as expected and new kernels appear to me in the selection list in petitboot.
-
The problem is it gets overwritten periodically.
-
It's not ideal but updating this script is rare, since the beginning of installing Fedora 37 it has not been updated once and the kernel several times ;)
-
Today systemd-251.13.-6 updated without any problems.