How to deal with AMD's new amdgpu-installer 20.40

Ask in English
, , , ,
#1

I’m sure I’m not the only person to have noticed this, but now that AMD isn’t providing RPMs directly, the new ‘amdgpu-install’ script is totally broken on Fedora, now. Yes, I know Fedora isn’t officially supported, but it’s been that way for 20 years, and it’s always worked, anyway.

amdgpu-install now tries to install a real yum remote repository, which sounds great, but the script produces a bad repo path, which causes the install to fail:

AMDGPU 21.40.1 repository                                            343  B/s | 178  B     00:00    
Errors during downloading metadata for repository 'amdgpu':
  - Status code: 404 for https://repo.radeon.com/amdgpu/21.40.1/rhel//main/x86_64/repodata/repomd.xml (IP: 13.82.220.49)
Error: Failed to download metadata for repo 'amdgpu': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Ignoring repositories: amdgpu
Last metadata expiration check: 0:18:33 ago on Mon 27 Dec 2021 17:14:43 PST.
No match for argument: amdgpu-lib
No match for argument: amdgpu-dkms
Error: Unable to find a match: amdgpu-lib amdgpu-dkms

Without studying the script in full, I’m not sure what is wrong, but I suspect it just doesn’t have a true code path for fedora, even though the string ‘fedora’ is in the script in a few places.

I’m going to try manually installing the RHEL8.5 repo, which should get me back to the old situation where I could at least try to install any AMD pkg I want.

#2

Okay, maybe I am the only person to experience this. I was able to restore functionality by manually installing more packages, ignoring installation errors, and rebooting, repeatedly–same as always. There seems to be no way to tell what are required and what are not. What a nightmare. Will this pain ever end?

#3

I’ve just found out that problem is in repo link in these files
/etc/yum.repos.d/amdgpu-proprietary.repo
/etc/yum.repos.d/amdgpu.repo

script doesn’t defines $amdgpudistro variable. I fixed link locally - replaced $amdgpudistro with “8.5”. After replacement amdgpu-install works fine. Running fresh Fedora 35

#4

You seem to be installing on fedora but the “8.5” refers to a RHEL version. Guess that the problem is due directly to using 3rd party repos, since the variable you noted ($amdgpudistro) is not set by dnf in fedora and the amdgpu repos seem to use something other than the fedora distro naming for the installation.

What is the actual URL for the installer to use for downloads? (from those repo files)

1 Like
#5

Tengo ese mismo problema.
vengo de Debian 11 y allí funcionaba correctamente mi tarjeta gráfica AMD RX570
con drivers de propietario AMG GPU PRO, resulta en fedora me devuelve que el link está reportado exploro el sitio y cambio de ubicación y están los archivos RPM pero a pesar que se instala 1 por uno no me acepta.
espero con ansias alguna solución

1 Like
#6

Please, when posting in the ‘Ask in English’ forum use the english language. If you wish to use spanish then please post in the ‘Ask in Espanol’ forum so the users are all able to read and reply in your language of choice.

Also, if this is a new problem for you please start your own thread so it gets the attention it deserves and can be easily found when searching.

#7

Hmm, interesting questing. I put:
https://repo.radeon.com/amdgpu/21.40.1/rhel/8.5/main/x86_64

But, that isn’t right, because it doesn’t get updates. There is a ‘latest’ directory, and I think that is probably what we should use:
https://repo.radeon.com/amdgpu/latest/rhel/8.5/main/x86_64/

#8

AMD, to my knowledge, has never supported Fedora for amdgpu-pro and whenever I’ve tried to install it on Fedora, it’s always been a very messy process that broke on the next kernel update. This is unfortunately a very real pain point for Radeon graphics that otherwise work wonderfully out of box on Fedora. As these are proprietary from AMD, there’s also not much of anything that can be done about it on the Fedora side. I would love for this to change so I could contribute more to BOINC projects like World Community Grid via OpenCL with my powerful RX cards. The best thing you can do is contact AMD support and hope that they’ll hear us.

#9

I’m not talking about their proprietary drivers; I’m talking about their OSS support. -pro works just like it does in Windows and no better on that platform than on Linux, so I don’t really care what they do over there. I’m talking about the stuff they keep promising to deliver, but always seem to fall short. You do not need -pro to crunch for BOINC, now or ever.

I’ve been crunching for BOINC for 22 years. And for the last 10 years, maybe more, I’ve been doing it with ATi/AMD GPUs. In the beginning, OpenCL just worked, no extra drivers necessary. Then it became necessary to install Catalyst, or at least I though it did, and that was about 4 years of my life I’ll never get back. Then there was another period where the OSS OpenCL worked without any extra AMD pkgs. But, since AMDGPU, it’s generally worked fine without -pro, and that is by design. (Contrast this with NVidia, where their drivers are required even for the desktop because nouveau lacked a lot of features–from what I gather, I only read stuff in passing about team green <boooo!>.)

The trouble is that the installer sucks, has always required root priv, and the documentation is terrible. But, there is nothing to tell AMD because they are always saying the right things in public about their support for the OSS community, and they make new commitments to bring new feature support to the OSS stack every year. I just wished they would contribute more, quicker.

It’s true, they have always excluded Fedora from the list of “supported” distros. But, they include plenty of RPM-based distros and they’re just being obstinate about it. Also, the “support” isn’t very good, so I fail to see what we are loosing by not having a case statement in the terrible installer just for Fedora. The RPM dependencies are all messed up, so you get this problem of trying to figure out what you need without any documentation. But, you have that same issue on any distribution.

The last few years have been pretty good. They have real RPMs for RH, which they didn’t in the beginning. But, now, without telling anyone, they actually have an RPM repo that will get updates. Why is it so hard to explain what they are doing?

I’m thrilled that I found this repo, today. I swear I checked for it before and I don’t remember finding the ‘latest’ directory back then. Anyway, this is another incremental step in the right direction. Now, after you get the right pkgs installed, which is trouble, you can at least update them like any normal RPM! Big milestone.

1 Like
#10

NO NO NO!

So, I tried to update my system and everything broke. Firefox wouldn’t even start. OMG, AMD, you drive me insane. I had to unstall AMDGPU. I’ll try to start all over again. Maybe 21.50 doesn’t work on F35.

#11

Well, there goes another 5 hours of my life. Just after I gave AMD praise, too. They got me again! I have no one to blame but myself, I guess. I really shouldn’t keep falling for it.

So, that “update” idea didn’t work at all. I finally got my system back and, as usual, it was so difficult that I don’t even remember how I ended up fixing it.

I did learn one thing very useful, though: it took way fewer packages than I had installed the last several times I did this. Check this out:

amdgpu-dkms.noarch                                1:5.13.11.21.50.50000-1373477.el8       @amdgpu-prd
amdgpu-dkms-firmware.noarch                       1:5.13.11.21.50.50000-1373477.el8       @amdgpu-prd
amdgpu-pro-core.noarch                            21.50-1373477.el8                       @amdgpu-proprietary
ocl-icd-amdgpu-pro.x86_64                         21.50-1373477.el8                       @amdgpu-proprietary

So, here’s one thing to watch out for: if you have amdgpu-install pkg installed, upgrading it will recreate your /etc/yum.repos.d/files, destroying any modifications you made to make the damn thing work in the first place. So, hint #1: build your own repo files so amdgpu installer cannot mess them up.

Also, it doesn’t look like you need amdgpu-install for exactly the reason I sited before: You’re better of without it! Hint #2: DO NOT INSTALL AMDGPU-INSTALL. Pretty much the worst thing you can do is follow AMD’s instructions. I think amdgpu-install is now worse than it has ever been for Fedora. It used to limp a long and work with some cheating, but not anymore.

So, here’s something else: when I finally gave up and decided to start over, I ran amdgpu-install --uninstall…but that failed, of course, and left me with a bunch of installed pkgs. I used dnf’s reporting of the install repo to find everything and back out. That’s Hint #4 if you didn’t already know about it.

Finally, I don’t even think the amdgpu-dkms pkgs do anything. Boot just throws a bunch of errors about them. So, I uninstalled them, and they didn’t affect the other pkgs. So, after all that pain, all I needed was TWO packages???

Oh, also, the gpg repo keys are in the amdgpu-install pkg. So, I guess you can either disable that for your repos or install it, copy the keys, and then uninstall it??? Whatever. I’ll fix it later. Need sleep.

1 Like
#12

Ranting Section

Okay so, I can’t stop picking at this…

I managed to mess it up, again, but recovered by reinstalling some installed packages. So here is my MWE for amdgpu 21.50:

$ sudo -i dnf list installed '*amdgpu*' '*rocm*' '*roct*' '*hsa*' | grep -v 'procmail|setproctitle'
Installed Packages
amdgpu-pro-core.noarch       21.50-1373477.el8           @amdgpu-proprietary-prd
hsa-rocr.x86_64              1.5.0.50000-49.el8          @rocm-prd              
hsakmt.x86_64                1.0.6-17.rocm3.9.0.fc35     @fedora                
hsakmt-roct-devel.x86_64     20211222.1.5.50000-49.el8   @rocm-prd              
ocl-icd-amdgpu-pro.x86_64    21.50-1373477.el8           @amdgpu-proprietary-prd
rocm-core.x86_64             5.0.0.50000-49.el8          @rocm-prd              
rocm-ocl-icd.x86_64          2.0.0.50000-49.el8          @rocm-prd              
rocm-opencl.x86_64           2.0.0.50000-49.el8          @rocm-prd              
rocm-runtime.x86_64          3.9.0-2.fc35                @fedora                
rocminfo.x86_64              3.9.0-2.fc35                @fedora                
xorg-x11-drv-amdgpu.x86_64   21.0.0-1.fc35               @fedora

But, that doesn’t tell the whole story. Consider these confusing factors:

  • There are no pkgs installed from the non-proprietary repo. That makes no sense at all, right? I’m trying to use the non-pro stack. Why are the pkgs I need both labelled ‘-pro’.
  • dnf tried to install amdgpu-core, but it failed, but that’s always been true, since amdgpu-core pkg was first introduced.
  • one of the most critical files is libamdocl64.so…but that’s not in amdgpu-pro-core
  • amdgpu-pro-core has only one file, the EULA agreement. Gee, thanks a lot.
  • libamdocl64.so is actuall in rocm-opencl
  • But, rocm-opencl is not a dependency of any other installed pkg!
  • Also, file /etc/ld.so.conf.d/10-rocm-opencl.confis required to get linking work. It points /opt/rocm-5.0.0/opencl/lib which contains libamdocl64.so
  • BUT no package owns /etc/ld.so.conf.d/10-rocm-opencl.conf! So, I have no idea what pkg install created it or how. Why would a package create a simple file with a script instead of just delivering the file?
  • Also, there are two copies of libOpenCL.so.1.2. I think one is for ROCm-based access to OpenCL and one is for, uh, normal OpenCL?
    – /opt/rocm-5.0.0/opencl/lib/libOpenCL.so.1.2
    – /opt/amdgpu-pro/lib64/libOpenCL.so.1.2
  • I don’t know if the ROCm stuff is strictly necessary for what I’m doing with OpenCL. ROCm seems critical from the way AMD talks about it, but that might be marketing. But, my system did seem to break when I uninstall it.

Arrgh!!!

What I learned: How to get OpenCL to work without installing AMDGPU-PRO (21.50)

  1. I suggest installing amdgpu-install, first. It will install some .repo files and the gpg key for those repos.
  2. Copy all of those and make your own .repo files with them; you have to have different names. It took some time, but now my repo configs are nice and clean, and I can install/remove pkgs from the remote repos.
  3. Then, uninstall amdgpu-install; it will delete the .repo files.
  4. Then, install
    – amdgpu-pro-core
    – ocl-icd-amdgpu-pro
  5. Now, check you configuration with clinfo. I know if my system is working when there are 2 “plaforms” detected. One is old OpenCL/Mesa/Clover and doesn’t work (although it should, it used to), and the other one is newer OpenCL and says “AMD-APP ([version])”, where [version] is what changes when you get an update. It’s worth keeping track of this!
  6. If you are lucky, in the future, try dnf update ??

So, because of this recent disaster, upgrading with dnf is still untested on Fedora. I suppose I could go back and test, but…no. I will report back here after then next release.

More about clinfo and why things are so difficult

The clinfo that comes with rocm (/opt/rocm…/) doesn’t give any errors. But, the default clinfo that is part of the base Fedora distro might give an error like this:

fatal error: cannot open file '/usr/lib64/clc/gfx1010-amdgcn-mesa-mesa3d.bc': No such file or directory

This is the reason the old OpenCL “platform” doesn’t work anymore. But, AFAIK, this is only a problem with NAVI10 (gfx1010/5700XT) GPUs. This missing file is the “secret sauce” that Mesa hasn’t been able to include, but is included for other, older cards, and is known to work without any extra amdgpu packages from AMD. It may also be a problem for the latest gen (6800s); I don’t have one to test. :frowning: But, don’t assume you need extra AMDGPU stuff to make OpenCL work; it didn’t used to be like this!

1 Like
#13

Okay, here we go! Looks like some admgpu packages were updated in the ‘…/latest/…’ RHEL 8.5 RPM repository. DNF seems to be doing the right thing by identifying them as updated, automatically. I’ll update and reboot and see how it goes…

#14

Hey, I think it worked. I installed the new pkgs from the AMD repo (manual repo config) with many other system updates and…no problems detected.

$ sudo -i dnf list installed '*amdgpu*' '*rocm*' '*roct*' '*hsa*' | grep -v 'procmail|setproctitle'
Installed Packages
amdgpu-pro-core.noarch       22.10-1395274.el8           @amdgpu-proprietary-prd
hsa-rocr.x86_64              1.5.0.50100-36.el8          @rocm-prd              
hsakmt.x86_64                1.0.6-17.rocm3.9.0.fc35     @fedora                
hsakmt-roct-devel.x86_64     20220128.1.7.50100-36.el8   @rocm-prd              
ocl-icd-amdgpu-pro.x86_64    22.10-1395274.el8           @amdgpu-proprietary-prd
rocm-core.x86_64             5.1.0.50100-36.el8          @rocm-prd              
rocm-ocl-icd.x86_64          2.0.0.50100-36.el8          @rocm-prd              
rocm-opencl.x86_64           2.0.0.50100-36.el8          @rocm-prd              
rocm-runtime.x86_64          3.9.0-2.fc35                @fedora                
rocminfo.x86_64              3.9.0-2.fc35                @fedora                
xorg-x11-drv-amdgpu.x86_64   22.0.0-1.fc35               @updates               
$ clinfo                                                             
Number of platforms                               2                     
  Platform Name                                   AMD Accelerated Parallel Processing
  Platform Vendor                                 Advanced Micro Devices, Inc.
  Platform Version                                OpenCL 2.1 AMD-APP (3423.0)
...
#15

I guess I should update the solution to this thread, now that I have been able to confirm that, at least for the most recent update, AMD’s public RPM repository can be made to work as expected.

Start here if you don’t have a copy of AMD RPM GPG signing key AND/OR you don’t want to create the RPM repository config files from scratch

  • Temporarily install amdgpu-install
  • Make a copy of all the new dnf/yum repo files in /etc/yum.repo.d for yourself.
  • Make a copy of the AMD RPM GPG signing key referenced by the gpgkey key in those repo files. You’ll need it for later. A good place to put it might be /etc/pki/rpm-gpg/ with all your other ones.
  • Uninstall amdgpu-install

Skip to here if you have a copy of AMD RPM GPG signing key AND you don’t need any help creating remote RPM repository configurations

  • Define your own remote RPM repository config files (/etc/yum.repos.d/) (or use the ones amdgpu-install installs as a guide from above) for each of the following:
    – amdgpu-[foo]
    – amdgpu-pro-[foo]
    – rocm-[foo]
    where [foo] is some string that differentiates your manually defined remote repositories from the ones amdgpu-install created. This is all so that it will not break when we uninstall it, or if you ever have to install amdgpu-install, again, it will not overwrite or ruin what you have done.
  • change the baseurl key configured for your new remote repos to point to the URL that will get updates, instead of the one amdgpu-install created, which points to a URL for just that specific version of amdgpu. (I know, it’s so crazy that it doesn’t make sense when you write it out.) There is still a different URL for each distribution, though. For F35, for example, I figure CentOS8 or RHEL/8.5 is the closest match, so, I used:
    – amdgpu:https://repo.radeon.com/amdgpu/latest/rhel/8.5/main/x86_64
    – amdgpu-pro:https://repo.radeon.com/amdgpu/latest/rhel/8.5/proprietary/x86_64
    – rocm:https://repo.radeon.com/rocm/centos8/rpm
    The key is the part of the URL that is ‘…/latest/…’; that’s all we are really achieving by doing all this. For rocm, there isn’t a ‘latest’, but whatever. Make sure the URL you are specifying exists using a web-brower or curl or something.
  • Update software package cache. I assume this works from GNOME Software, but I didn’t test. I used sudo -i dnf makecache. That should list the new repositories you created and fetch the available packages. If it’s working, you can now browse the remote repository however you like.
  • install just the packages you want. I still don’t know what is MWE. I think you just need ocl-icd-amdgpu-pro (and it’s dependencies), but I found ldd was linking to a .so in rocm-opencl, so I’m leaving that installed, plus it’s dependencies. I don’t think you really need any HSA stuff.
2 Likes