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?
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)
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.
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.
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.
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.)