I completely get it. It’s rad to be on 1024x768 resolution, like in the old days. But it’s 2024 people and I’m on not so old and not so new hardware (5600g amd cpu/igpu).
At least give an option after installation to change the setting so that the rest of us who want to use our GPU without being nerfed with a crappy framebuffer can do so.
From Project Discussion to Ask Fedora
Added amdgpu, f40 and removed engineering
That is very surprising.
Did you do a fresh install or an upgrade?
I fresh installed ’ Fedora KDE Plasma Desktop 40’ after a botched update from power loss. I don’t remember nomodeset being there when I installed Fedora a few months ago.
Jul 7 12:43:42 fedora kernel: Linux version 6.8.5-301.fc40.x86_64 (mockbuild@0bc0cc78c12e4762acf61c209bd02e96) (gcc (GCC) 14.0.1 20240328 (Red Hat 14.0.1-0), GNU ld version 2.41-34.fc40) #1 SMP PREEMPT_DYNAMIC Thu Apr 11 20:00:10 UTC 2024
Jul 7 12:43:42 fedora kernel: Command line: BOOT_IMAGE=(hd4,gpt2)/vmlinuz-6.8.5-301.fc40.x86_64 root=UUID=6d3c61ec-14dd-45ec-b228-a6deeba5ad7c ro rootflags=subvol=root nomodeset rhgb quiet
This is first time I have heard of this.
Suggest you you fix for yourself and we will watch out for others reporting the same issue.
After updating my system, the nomodeset is back. This is getting really irritating. I really don’t want to be ‘distro hopping’ just to find a stable system less hassle system.
grep -R nomodeset /etc
grub2-efi.cfg: set kernelopts="root=UUID=6d3c61ec-14dd-45ec-b228-a6deeba5ad7c ro rootflags=subvol=root nomodeset rhgb quiet "
grub2.cfg: set kernelopts="root=UUID=6d3c61ec-14dd-45ec-b228-a6deeba5ad7c ro rootflags=subvol=root nomodeset rhgb quiet "
Did you use grubby commands to remove the nomodeset?
You will need to to stop the option being propergated on each new kernel install.
Okay, nevermind that. I don’t see anything in the logs to indicate nomodeset was re-set. However, after installing the latest system update, it booted into 1024x768 screen resolution. I had to reboot to fix that.
Is Fedora 40 stable? I was under the impression it was fairly stable. I’ve been using Linux since the '90s so I can deal with some issues, but I prefer not to deal with problems all the time.
For the 7 Fedora systems I run its to very stable.
I use kde plasma, server, VMs, music server.
Ok I installed Fedora 40 fresh on the 7th of July. Updated immediately. Then updated again today.
mesa was included in the update. This the log immediately after the update:
Jul 14 02:50:38 box systemd[1197]: Started wireplumber.service - Multimedia Service Session Manager.
Jul 14 02:50:38 box rtkit-daemon[931]: Successfully made thread 1233 of process 1233 (/usr/bin/pipewire) owned by '988' high priority at nice level -11.
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "kwin_scene_opengl: No render nodes have been found, falling back to primary node\n"
Jul 14 02:50:38 box rtkit-daemon[931]: Successfully made thread 1261 of process 1233 (/usr/bin/pipewire) owned by '988' RT at priority 20.
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:38 box rtkit-daemon[931]: Successfully made thread 1259 of process 1259 (/usr/bin/wireplumber) owned by '988' high priority at nice level -11.
Jul 14 02:50:38 box kernel: warning: `QSampleCache::L' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "libEGL warning: MESA-LOADER: failed to open simpledrm: /usr/lib64/dri/simpledrm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)\n\n"
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "libEGL warning: MESA-LOADER: failed to open simpledrm: /usr/lib64/dri/simpledrm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)\n\n"
Jul 14 02:50:38 box systemd[1197]: Started pipewire-pulse.service - PipeWire PulseAudio.
Jul 14 02:50:38 box rtkit-daemon[931]: Successfully made thread 1291 of process 1291 (/usr/bin/pipewire) owned by '988' high priority at nice level -11.
Jul 14 02:50:38 box rtkit-daemon[931]: Successfully made thread 1297 of process 1291 (/usr/bin/pipewire) owned by '988' RT at priority 20.
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "MESA: error: ZINK: failed to choose pdev\n"
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "MESA: error: ZINK: failed to choose pdev\n"
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "libEGL warning: egl: failed to create dri2 screen\n"
Jul 14 02:50:38 box sddm-helper-start-wayland[1210]: "libEGL warning: egl: failed to create dri2 screen\n"
Jul 14 02:50:41 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:41 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:41 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:41 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:41 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:42 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:42 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:42 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:42 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:42 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
Jul 14 02:50:42 box sddm-helper-start-wayland[1210]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"
the kwin_wayland_drm was blitzing the logs until I rebooted, and the issue seems to have corrected itself.
I did do a ‘grub2-mkconfig’ before rebooting, but I’m not sure if that actually changed anything, at least to resolve that problem, and nomodeset didn’t appear to be set, I just assumed it was because I was back at 1024x768 resolution again.
Looks like I’m not the only one.