Tryging to run F41 on old machine with ATI Radeon 5000 - black screen

Hi,

I’m trying to run F41 on an old machine, which has an ATI RADEON card, but the display wont run without using nomodeset in the kernel args. This limit my display to 800x600 only.

Dose anyone know how to resolve this?

If I’m reading the chart right, your card needs the radeon driver. Maybe you need to blacklist the amdgpu driver and force the radeon driver? You might need to create a config file with add_drivers+=" radeon " under /etc/dracut.d and then run sudo dracut -f to get the radeon driver in your initramfs. You can use sudo lsinitrd | grep radeon.ko to confirm that the driver has been added to your initramfs.

Thank you @glb for the quick and thought respond, but unfortunately it didn’t help,

I added amdgpu to the blacklist with echo 'blacklist amdgpu' > /etc/modprobe.d/amdgpu.conf
I added the radeon driver with add_drivers+= and I do see it with lsinit

From what I can see, the initramfs boot OK and I see the text starting to scroll, I guess it fail once the root switch happens.

How about if you add rd.driver.pre=radeon on your kernel command line? Otherwise, maybe you can find some hints about what the problem might be by grep’ing the output of sudo dmesg for things like “radeon”.

Also, does the output of lsmod (and/or lspci -k) show that the radeon driver is being used?

Edit: You might try adding rd.driver.blacklist=amdgpu as well.

Edit2: When it fails, I guess it is just the video driver that fails? (e.g. The HDD indicator light still shows activity?) You might try setting a low-res video mode that you know works with something like video=800x600 just to be sure it isn’t trying to set a mode that your monitor (or card) doesn’t support.

Edit3: Maybe also remove rhgb and set plymouth.enable=0 in case plymouth is causing problems or hiding important error messages.

rd.driver.pre=radeon also didn’t work, and the journal is not showing any hints about radeon

# journalctl -b | grep -iw -e ati -e radeon
ינו 09 02:24:15 ariel-pc kernel: input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card1/input21

The old log show the dracut output,

# journalctl -b1 | grep -iw -e ati -e radeon | head
ינו 08 18:54:09 ariel-pc kernel: input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card1/input21
ינו 08 18:54:14 ariel-pc alsactl[814]: Found hardware: "HDA-Intel" "ATI R6xx HDMI" "HDA:1002aa01,00aa0100,00100200" "0x174b" "0xaa68"
ינו 08 21:11:26 ariel-pc dracut[10895]: drwxr-xr-x   2 root     root            0 Nov 27 02:00 usr/lib/firmware/radeon
...

Also tried now setting

rd.driver.pre=radeon rd.driver.blacklist=amdgpu video=800x600 plymouth.enable=0

and it didn’t change anything, (it fills like the systems hangs) :face_exhaling:

Maybe dig through the AMD bug tracker and see if you can find reports of similar problems (and maybe some workarounds). I think the “Radeon” tag should narrow the results to ones that might be relevant to you.

Does the numlock key still respond to change the LED on your keyboard? Try removing quiet and adding debug to maybe get more messages about what is happening during boot.

I installed Fedora 41 on an old Mac Pro (2013) with AMD Fire Pro 300’s and continued to get a black screen. I needed to use the amdgpu drivers and a got them all set in grub but still had the black screen issue. came across this thread:

I set my system to use xorg and it booted into the gui. I ssh into the Mac Pro to make the changes then rebooted. Apparently from what I have gathered there is a issue with gdm / wayland support on some old hardware. Did not have this issue up to F39.

This is what I did:

Open /etc/gdm/custom.conf.
Uncomment the line WaylandEnable=false.
Right after that, add DefaultSession=gnome-xorg.desktop.

This brings back the login screen and lets me log into the desktop normally.

The clue for me was that I was able to ssh into the Mac Pro, so it was booted up but gdm running under wayland was failing before the gui could be loaded.

1 Like

I installed the X11 packages, and also switched SDDM to use x11, and using nomodeset I was able to login to X11 session, but when I tried with/o nomodeset it failed the same.

Numlock seems to be working, but nothing happens, I don’t have network connectivity to ssh into the machine.

Do the Virtual Terminals work? Can you press Ctrl+Alt+F3, for example, to swith to VT3?

How about booting to multi-user mode by adding systemd.unit=multi-user.target on the kernel command line. If you can get a console working, then maybe you will be able to find some more logs or otherwise troubleshoot the problem further.

After re-reading your post:
In your old log above it says your found hardware was the ATI R6xx not the 5000?

You might try running inxi -Gxx in the terminal if you can get to one and get detailed info on what Graphics devices and drivers that are loaded.

i.e. $ inxi -Gxx (May have to dnf install inxi)

Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Curacao XT / Trinidad [Radeon R7
    370 R9 270X/370X] vendor: Apple FirePro D300 driver: amdgpu v: kernel
    arch: GCN-1 pcie: speed: 8 GT/s lanes: 16 ports: active: none empty: DP-1,
    DP-2, DP-3, DP-4, DP-5, DP-6 bus-ID: 02:00.0 chip-ID: 1002:6810
    temp: 52.0 C
  Device-2: Advanced Micro Devices [AMD/ATI] Curacao XT / Trinidad [Radeon
    R7 370 R9 270X/370X] vendor: Apple FirePro D300 driver: amdgpu v: kernel
    arch: GCN-1 pcie: speed: 8 GT/s lanes: 16 ports: active: DP-10
    empty: DP-11, DP-12, DP-7, DP-8, DP-9 bus-ID: 06:00.0 chip-ID: 1002:6810
    temp: 54.0 C
  Display: x11 server: X.Org v: 21.1.15 with: Xwayland v: 24.1.4
    compositor: gnome-shell v: 47.2 driver: X: loaded: amdgpu
    unloaded: modesetting,radeon alternate: fbdev,vesa dri: radeonsi
    gpu: amdgpu display-ID: :1 screens: 1
  Screen-1: 0 s-res: 3840x2160 s-dpi: 96
  Monitor-1: DP-10 mapped: DisplayPort-9 model: Dell U4320Q res: 3840x2160
    dpi: 104 diag: 1080mm (42.5")
  API: OpenGL v: 4.6 vendor: amd mesa v: 24.3.2 glx-v: 1.4 es-v: 3.2
    direct-render: yes renderer: AMD Radeon R9 200 Series (radeonsi pitcairn
    LLVM 19.1.5 DRM 3.59 6.12.7-200.fc41.x86_64) device-ID: 1002:6810
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
1 Like

When posting text that you copy from the screen please use the preformatted text tags so the display here remains as seen on-screen. Things are much more readable when that is done.
The preformatted text tags are gotten by one of 2 ways.
Either add ``` to the lines immediately before and after the text
or
paste the text then highlight it and click the </> button on the toolbar of the text entry window. (which adds those characters as noted)

I have taken the liberty of editing your inxi post to add those tags. Note the difference in the way it is formatted.

Thanks for the tip and fixing

I have a Dell Precision M6500 with FireGL (shows as HD 5000 series), and it worked fine F41 Workstation GNOME Wayland about a week ago built-in display and over DisplayPort.

I see Plasma is used; I can’t see why that’d make a difference (unless they’re enforcing Vulkan/higher GPU stuff OTB) but I know it worked from GNOME 47 at least.

1 Like

Does it use the old radeon driver or the newer amdgpu driver? I’m never sure when trying to read those charts.

There is a difference between Plasma and GNOME. In my multiple attempts to install F41 on my system Fedora 41 KED Plasma was the only version that would install and get to the gui after setup. Ended up doing another install of Fedora Workstation with GNOME as the Plasma setup had one of my cores pegged at 100% all the time. From other discussions on this board Vulkan was brought up as a possible issue for this.

Older radeon (iirc under a Xorg ati package)

I didn’t check CPU load (the install didn’t last long), but if GNOME’s use for Vulkan was a problem, switching to OpenGL with GSK_RENDERER=ngl (or gl) might be helpful.

Do the Virtual Terminals work? Can you press Ctrl+Alt+F3, for example, to swith to VT3?
Nothing all blank. I get no response.

How about booting to multi-user mode by adding systemd.unit=multi-user.target on the kernel command line.

I tried that, but again, once the kernel boot with/o the nomodeset it blocked, and when I booted with nomodeset it worked, but then I had another issue, when the NIC was not working, so I gave up on it. But will try again.

Problems with the display adapter can be very hard to troubleshoot. Sometimes people run a null-modem cable between two computers so they can see more of the kernel’s debugging output before it hangs. (You would also need to add console=ttyS0,19200n8 to the kernel command line on the computer that is locking up and use a command such as screen /dev/ttyS0 to connect from the monitoring computer.)