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
I went ahead and tried the "nomodeset" kernel parameter, and it resulted in the same issue, Kamal and Ben had (https://bugs.gentoo.org/show_bug.cgi#c17). Using cat on /proc/fb outputted "0 EFI VGA".
I acquired an asus branded nvidia rtx 4070 super to test the isos / workaround. Platform used: qemu vm, kvm virtualization, host cpus vfio-pci to present the graphics card (video and audio) to guest vfio-pce to present usb controller/ports to the guest disabled vga (emulated video) Relevant options passed to qemu: -device vfio-pci,host=16:00.0 # gpu card pci address for video -device vfio-pci,host=16:00.01 # gpu card pci address for sound -device vfio-pci,host=00:14.0 # usb port pci address (so kb works) -vga none # disables emulated gpu Full qemu command line: qemu-system-x86_64 -enable-kvm -cpu host -machine q35 -monitor stdio -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -bios /home/virtuals/liveiso/fw/OVMF_CODE-pure-efi.fd -boot order=c -name liviso -device virtio-net,netdev=net0,mac=de:ad:be:ef:50:87 -netdev tap,id=net0,script=/home/virtuals/scripts/admin/tun-up.sh -m 12G -smp 6 -drive file=/home/virtuals/liveiso/storage/storage.qcow2,if=virtio,id=drive0 -drive if=pflash,format=raw,unit=0,readonly=on,file=/home/virtuals/liveiso/fw/OVMF_CODE-pure-efi.fd -drive if=pflash,format=raw,unit=1,file=/home/virtuals/liveiso/fw/OVMF_VARS-pure-efi.fd -cdrom /home/virtuals/isos/revised-livegui-amd64-nvidia.iso -device vfio-pci,host=16:00.0 -device vfio-pci,host=16:00.01 -device vfio-pci,host=00:14.0 -vga none ISOs tested: livegui-amd64-20241222T164831Z.iso --curent gui iso revised-livegui-amd64-nvidia.iso --fallback mesa protocol, amd64 kernel renvised-livegui-2-amd64-nvidia.iso --nouveau blacklisted, amd64 kernel livegui-amd64-nvidia.iso --present ~arch64 kernel on stable iso Results: Only the kernel presently kw ~amd64 properly booted to a gui Both other isos report the gpu device is unknown to the nouveau driver "nouveau 0000:00:03.0: unknown chipset (194000a1)" output from lspci on all isos report the device being bound to nouveau (exception being where nouveau was blacklisted) rc-status output on all isos report all services running (not crashed) iso with fallback protocols would not load gui even after modprobe -r nouveau blacklisting nouveau had the same results are modprobe -r of it the present kernels marked stable will not support the newer gpus as-is cli parameters/mesa will not compensate for the driver not supporting the card blacklisting nouveau to force use a fb based gui driver presently fails Attachments: I will attach logs from each of the isos tested. I've colllected output of: lspci -vnnk + dmesg + messages file from each boot Any further info needed from booting the isos can be obtained upon request
Created attachment 915506 [details] output from livegui-amd64-20241222T164831Z boot present stable gui iso
Created attachment 915507 [details] output from stable iso with modified mesa to include fallback fallback mesa libs included into iso
Created attachment 915508 [details] output from stable iso with nouveau blacklsited stable gui iso with nouveau blacklisted
Created attachment 915509 [details] output from stable iso using 6.12.7-gentoo-dist kernel ~arch kernel included in iso
$ grep "Linux version 6\|unknown chipset" ./*/dmesg* ./blacklisted-nouveau/dmesg.txt:[ 0.000000] Linux version 6.6.67-gentoo-dist (portage@localhost) (x86_64-pc-linux-gnu-gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221, GNU ld (Gentoo 2.43 p3) 2.43.1) #1 SMP PREEMPT_DYNAMIC Mon Dec 30 04:56:48 UTC 2024 ./kernel~arch/dmesg.txt:[ 0.000000] Linux version 6.12.7-gentoo-dist (portage@localhost) (x86_64-pc-linux-gnu-gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221, GNU ld (Gentoo 2.43 p3) 2.43.1) #1 SMP PREEMPT_DYNAMIC Sun Dec 29 06:06:49 UTC 2024 ./livegui-amd64-20241222T164831Z/dmesg.txt:[ 0.000000] Linux version 6.6.62-gentoo-dist (portage@localhost) (x86_64-pc-linux-gnu-gcc (Gentoo 14.2.1_p20241116 p3) 14.2.1 20241116, GNU ld (Gentoo 2.42 p6) 2.42.0) #1 SMP PREEMPT_DYNAMIC Sun Nov 24 22:37:56 UTC 2024 ./livegui-amd64-20241222T164831Z/dmesg.txt:[ 6.416788] nouveau 0000:00:03.0: unknown chipset (194000a1) ./modifified-mesa.txt/dmesg.txt:[ 0.000000] Linux version 6.6.67-gentoo-dist (portage@localhost) (x86_64-pc-linux-gnu-gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221, GNU ld (Gentoo 2.43 p3) 2.43.1) #1 SMP PREEMPT_DYNAMIC Mon Dec 30 04:56:48 UTC 2024 ./modifified-mesa.txt/dmesg.txt:[ 5.498887] nouveau 0000:00:03.0: unknown chipset (194000a1)
First of all, thanks tdr for testing all these setups for us! I've managed to get some user feedback and can confirm only nvidia 4000 series GPUs have this issue. The test data proves once 6.12 becomes LTS shortly then the issue goes away, however it will (likely) return when the 5000 series cards drop. So I think the longterm fix is to enable software rendering graphics output then create a second boot option in the GRUB menu which blacklists all drm modules. Looking into how Mint get around this issue is another idea too.
I think I have kind of a similar issue, but I'm using an Intel iGPU rather than an Nvidia one. `startx` was giving me a weird "bad display name" error, and the forums implied this was a bug, but they didn't elaborate, and this was the only seemingly-relatable bug I could find. My iGPU is an 8086:7d55, which, according to Intel (https://dgpu-docs.intel.com/devices/hardware-table.html), requires the use of the `force_probe` driver parameter, and says it's only supported in the 6.8 kernel, which isn't even stable in gentoo-sources yet. But, I did get it to work using the livegui-amd64-20250202T154819Z.iso image with the following commands: sudo modprobe -r i915 sudo modprobe i915 force_probe=7d55 And immediately afterward, it started KDE.