Created attachment 901619 [details] Screengrab of boot issue The latest LiveGUI image with timestamp 20240825T170406Z doesn't boot into KDE - it just drops into the command line. Trying to start X manually shows some errors about unable to connect to X server. I see errors from xinitrc like "xterm: command not found", "xclock: command not found", etc. An earlier build 20240714T170402Z is fine. Something must have broken in the latest build?
Resolved with https://bugs.gentoo.org/938147
Too many tabs open problem....
Thanks
The problem still occurs with the versions of 30/8.
As a quick update, This is still being looked into but in the meantime as a workaround please use this known working version https://mirror.reenigne.net/gentoo-snapshots/2024-07-19-0600/releases/amd64/autobuilds/current-livegui-amd64/livegui-amd64-20240714T170402Z.iso (checksum https://mirror.reenigne.net/gentoo-snapshots/2024-07-19-0600/releases/amd64/autobuilds/current-livegui-amd64/livegui-amd64-20240714T170402Z.iso.sha256 )
The version of 18/8 (https://ftp.belnet.be/pub/rsync.gentoo.org/gentoo/releases/amd64/autobuilds/20240818T143401Z/) is probably the last good version.
I ran into this problem as well. Didn't know there was a bug report, should have checked. Also found the livegui-amd64-20240818T143401Z.iso was the only one of the 3 tried that would boot up to a GUI. Didn't try 402Z.
This issue began once all amd64 live media switched to dist-kernel. For the admin and installcd we disable DRM in the kernel but the livegui needs these. Catalyst creates binpkgs which are shared between the installcd and livegui but as we currently do not have a way to tell portage/catalyst that there is a config change inside it will just pick the newest one and we get a lucky dip on which config is applied to all builds after. 4 solutions as a workaround until a better fix can be found are: 1) always binpkg-exclude gentoo-kernel 2) start enabling DRM & re-add big firmwares to minimal+admincd 3) use some quick hack to differentiate the binpkgs (like USE=experimental) 4) Split the installcd and livegui packages out from each other
Option #3 is in progress... we added USE=experimental but didn't realize that current stable gentoo-kernel doesn't have the flag yet. We can try to kick of another build run some time this week with the fix. The livegui iso that will get published already tonight or tomorrow will not have the fix yet.
The latest LiveGUI image (20241006T144834Z) and the oldest available LiveGUI image (20240915T163400Z) are still having the issue where it doesn't boot into KDE and just drops into the command line.
Please share dmesg output
Created attachment 905869 [details] output of dmesg
(In reply to Guest5 from comment #12) > Created attachment 905869 [details] > output of dmesg Thanks, can you also share "lspci -nnk" output?
I've looked a bit closer and deduced that you're on some newer nvidia gpu-- we will need to investigate what the correct fallback for GUI is supposed to be, when DRM_NOUVEAU is not suitable.
Created attachment 905960 [details] lspci -nnk output (In reply to Ben Kohler from comment #13) > (In reply to Guest5 from comment #12) > > Created attachment 905869 [details] > > output of dmesg > > Thanks, can you also share "lspci -nnk" output? Here you go
Can you test adding the "nomodeset" kernel parameter via grub's boot menu, and find out: 1) If sddm & plasma start up 2) If the user experience is ok
I've been having the same issue with the liveGUI, added `nomodeset` to params and it attempted to into the DE, but once it was past the command line the screen was constantly blinking two black screens. One screen was an empty command line and the other a mouse cursor. I can provide lspci and dmesg if needed.
Let me explain what (I believe) is going on here. Due to a change in upstream (systemd-)logind [1], framebuffer devices like /dev/fb0 are no longer considered "master-of-seat" which means they are not considered usable by logind & sddm. So if you boot with only efifb, sddm sits there waiting on logind to find a usable display. That same rules file has this exception to allow using fb0 if nomodeset is passed: # Allow efifb / uvesafb to be a master if KMS is disabled SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", IMPORT{cmdline}="nomodeset", TAG+="master-of-seat" So that is where the 'nomodeset' suggestion came from. I have tested in qemu with efifb-only + nomodeset and was able to successfully start sddm/plasma, but I'm not able to test on newer nvidia gpu hardware. I'm curious if anyone else on nvidia hw has success with nomodeset here. For those not having success, I wonder if efifb is the driver in use or not. Can you check /proc/fb? When efifb is active it should show "0 EFI VGA". [1] https://github.com/systemd/systemd/commit/6260d28b8a
Minor update to that-- my standard gentoo install in qemu is able to start plasma with efifb & nomodeset. When I try the same on livegui, I get the blinking screens as Kamal mentions in comment 17. So 'nomodeset' makes sddm at least TRY to start but it's still failing on the livegui for some reason.
I think I found it, staring me in the face. According to nouveau.freedesktop (can't post the link :p ) Nov, 2023: AD10x and GSP support merged in Linux 6.7. `uname -r` yields: `6.6.51-gentoo-dist` and using `modinfo nouveau` shows: `6.6.51-gentoo-dist SMP preempt mod_unload`. The kernel version might explain why my Realtek NIC and Wifi module don't load properly, (with the latter not loading the driver properly).
Created attachment 906213 [details] dmesg.txt - Kamal uploading my dmesg, lspci to follow
Created attachment 906214 [details] lspci -nnk | Kamal my lspci output
