Fedora used to have fancy modules for things like node, which allowed fast install and switch of a specific version: https://developer.fedoraproject.org/tech/languages/nodejs/nodejs.html e.g. with dnf module install nodejs:8

This is no longer the case starting with Fedora 38: https://fedoraproject.org/wiki/Changes/NodejsRepackaging – which suggests to install an alternative [supported] version e.g. with dnf install nodejs18. While this works it did not adjust the default link of /usr/bin/node to nodejs18, like the old command would have done, so ANY not-packaged-for-Fedora project will still default to /usr/bin/node, which points in my case to node-20 at the time of writing. The article suggests to make use of the update-alternatives command to change this but it does not give an example.

And since I will forget this by tomorrow here is one, that adds a new entry for node to alternatives and adds a symlink for /usr/bin/node to /usr/bin/node-18 with a priority of 18:

> sudo update-alternatives --install /usr/bin/node node /usr/bin/node-18 18
> update-alternatives --list

Should there be one with a higher priority already, and the list not update with the command, it has to be overridden with a manual setter:

> sudo update-alternatives --set node /usr/bin/node-18
> update-alternatives --list

yw.

TIL: google-chrome ships a script to maintain and update signatures to `/etc/cron.daily/google-chrome`

This failed and brought down the whole update progress in the background due to an unknown signature for the google-chrome package

Found out by chance today – updates are usually that smooth that I didn’t notice they stalled for weeks o0

> The GPG keys listed for the “google-chrome” repository are already installed but they are not correct for this package.
> Error: GPG check FAILED

Solution was to run that script manually (as root) so it could update it’s repository config.

So didn’t show my GPU on when started via . I have an and all the (#ROCr / ) stuff installed. It only listed the iGPU by Intel on startup:

[---] OpenCL: Intel GPU 0: Intel(R) UHD Graphics 630 (driver version 23.35.27191.9, device version OpenCL 3.0 NEO, 25561MB, 2556>
[---] libc:  version 2.37

This works however fine when I run boinc manually as user (or clinfo for the matter), and not via systemctl start boinc-client, so I guessed it’s some permission issue. journalctl had the context I was looking for and threw this in the middle of the boinc-client startup:

audit[305157]: AVC avc:  denied  { read write } for  pid=305157 comm="boinc" name="kfd" dev="devtmpfs" ino=532 scontext=system_u:system_r:boinc_t:s0 tcontext=system_u:object_r:hsa_device_t:s0 tclass=chr_file permissive=0

This is SELinux’s charming way of telling me that it blocked read and write access to /dev/kfd (the main compute interface shared by all GPUs, according to the ROCm manual) for the boinc process. Nice. So what most users do now is grumble and disable SELinux, which is kinda a bad idea. The more advanced user does this and calls it a day:

sudo ausearch -c 'boinc' --raw | audit2allow -M boinc
sudo semodule -i boinc.pp

This basically prepares an override policy based on any rejected boinc activity that looks in my case like this:

module boinc 1.0;

require {
	type hsa_device_t;
	type random_device_t;
	type boinc_t;
	class chr_file { ioctl map open read write };
}

#============= boinc_t ==============
allow boinc_t hsa_device_t:chr_file { ioctl map open read write };
allow boinc_t random_device_t:chr_file write;

Not today though. It left me befuddled with the following output:

libsemanage.semanage_direct_install_info: Overriding boinc module at lower priority 100 with module at priority 400.
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/boinc/cil:3
Failed to resolve AST
semodule:  Failed!

…and I have no idea why. I also found nothing on Google Search. So to not be DenverCoder9 (https://xkcd.com/979/) in the future here is what I found out so far:

sudo cat /var/lib/selinux/targeted/tmp/modules/400/boinc/cil | bunzip2 
(typeattributeset cil_gen_require hsa_device_t)
(typeattributeset cil_gen_require random_device_t)
(typeattributeset cil_gen_require boinc_t)
(allow boinc_t hsa_device_t (chr_file (ioctl map open read write)))
(allow boinc_t random_device_t (chr_file (write)))

Apparently it can’t resolve the required typeattributeset boinc_t – which is kinda odd as it exists (see sudo semodule -X 100 --cil -E boinc and the resulting cil file). Frankly this is where SELinux lost me too. I found the man page for boinc_selinux, which is not really known on my Fedora system here, so I may be missing something. It suggests to enable permissive mode for boinc_t (instead of dropping SELinux altogether):

Note: semanage permissive -a boinc_t

can be used to make the process type boinc_t permissive. Permissive process types are not denied access by SELinux. AVC messages will still be generated.

https://linux.die.net/man/8/boinc_selinux

And sure enough on the next restart my AMD GPU became available:

[---] OpenCL: AMD/ATI GPU 0: AMD Radeon RX 6700 XT (driver version 3558.0 (HSA1.1,LC), device version OpenCL 2.0, 12272MB, 12272>
[---] OpenCL: Intel GPU 0: Intel(R) UHD Graphics 630 (driver version 23.35.27191.9, device version OpenCL 3.0 NEO, 25561MB, 2556>
[---] libc:  version 2.37

Happy numbers crunching. Mebbe some fix for SELinux crosses my path in the future so I can update this with the proper solution.

I didn’t use my Steam Link for some time and was kinda surprised by the new UI in Big Picture Mode. And also very unhappy because it was a stutter feast with buffer artefacts all over the place. Once I could get a game running it was butter though so something was up with the streaming mode of the UI. I’ve no really an idea what’s going on there but this was always a problematic thing with my AMD GPU under Gnome using Wayland when it comes to streaming and remote play. I ticked off the basics and disabled the blocklist for unknown GPUs, made sure that AMD hardware acceleration was enabled for the host in the Big Picture setting and even tried to launch it with the old big picture mode but no dice:

steam pipewire -pipewire-dmabuf -oldbigpicture

After reading around a lot on the bugtracker at https://github.com/ValveSoftware I eventually learned that the hardware acceleration for remote play is usually done with VAAPI and that there is debug information in ~/.local/share/Steam/logs/streaming_log.txt and sure enough here it was:

ffmpeg verbose: libva: VA-API version 1.16.0
ffmpeg verbose: libva: User environment variable requested driver 'radeonsi'
ffmpeg verbose: libva: Trying to open /usr/lib/dri/radeonsi_drv_video.so
ffmpeg verbose: libva: Found init function __vaDriverInit_1_16
ffmpeg verbose: libva: va_openDriver() returns 0
ffmpeg verbose: Initialised VAAPI connection: version 1.16
ffmpeg verbose: VAAPI driver: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6700 XT (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64).
ffmpeg verbose: Driver not found in known nonstandard list, using standard behaviour.
ffmpeg verbose: Input surface format is nv12.
ffmpeg verbose: Compatible profile VAProfileH264Main (6) is not supported by driver.
ffmpeg error: No usable encoding profile found.

So the profile was missing and a check with vainfo confirmed this:

vainfo --device /dev/dri/renderD128 --display drm
Trying display: drm
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6700 XT (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileAV1Profile0            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

This was the moment when my brain did pull off one of it’s tricks and remembered me about the story about Fedora _disabling_ hardware acceleration for H264 due to proprietary concerns some months ago and yes I did recently upgrade to Fedora 37 🤯

Thankfully the community stepped in already and fixed mesa drivers are only one dnf install away on rpmfusion, so there is no need to recompile this with h264 support (and some others) manually. There is a caveat though because the swap command would happily delete the needed 32bit versions for Steam and only install the 64bit version of the swapped package. Keeping this in mind the required commands are basically this (and if this breaks your system I do not want to hear about it – use your brain!):

dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
dnf update
dnf swap mesa-va-drivers mesa-va-drivers-freeworld
dnf install mesa-va-drivers-freeworld.i686

And sure enough vainfo now has a way more complete list – including the previous missing VAProfileH264Main profile:

libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.3.5 for AMD Radeon RX 6700 XT (navi22, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileAV1Profile0            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

And sure enough the Steam Link started working again. Somewhat. Now I have issues that some games don’t get captured or loose focus eventually but that I’ll debug another day 😩

Video: Starting Steamworld Dig 2 and showing system overview

Linux Gaming in 2023 is easy. Remote Play… not so much.

Hell yeah, and the experience: https://fedoramagazine.org/obs-studio-and-fedora-linux-an-interview-with-georges-basile-stavracas-neto/

Oh gods I can’t tell how much the dialogs that pop up every time I open OBS Studio annoy me because it can’t remember or recover previous screencasts and I’ve plenty in my scenes. That’s my most sour point after switching to nowadays. Real heroes at work right there!

AusweisApp2 unter Ubuntu nutzen by an author (blog.purelinux.de)
Neulich bin ich in die Welten der digitalen deutschen Behörden vorgedrungen. Mit AusweisApp2, RFID Kartenleser und Personalausweis konnte ich bequemer als gedacht mein Auto ummelden. Ein Erfahrungsbericht. Wie es dazu kam… Ich bin vor wenigen Monaten umgezogen (was auch die Ruhe auf dem Blog erkl...

Gut zu wissen. Dann bekomme ich das eventuell unter Fedora dann reproduziert, wenn der neue Ausweis dann mal fertig wird.

How To Install Docker On Fedora 32 Or 31 (And Alternatives) (Linux Uprising Blog)
Fedora 32 and 31 switched to cgroup v2, and due to this Docker no longer works. This article explains your options, and how to install Docker on Fedora 32 or 31 if you don't like the alternatives.

Use they said. Deploy will be so much easier they said.

If I get this right I have to choose between three different engines and two versions of cgroups on by now – let’s not start talking about docker-compose alternatives.

Needless to say that some very aged files will fail anyway no matter what path I choose 🤦

Sometimes I’m really tired of all this tech stuff

I checked some old disks of mine and found to my utmost joy a copy of my former installation. Well, is hard because who can support 500 distributions, right? How comes this just works in 2020 on 31? 😀