Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 938718 - Latest LiveGUI doesn't boot to GUI
Summary: Latest LiveGUI doesn't boot to GUI
Status: CONFIRMED
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: LiveCD/DVD/USB (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Release Team
URL:
Whiteboard:
Keywords:
Depends on: 945023 947325
Blocks:
  Show dependency tree
 
Reported: 2024-08-30 06:03 UTC by bdforbes
Modified: 2025-02-12 05:42 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Screengrab of boot issue (Gentoo LiveGUI boot issue.png,20.12 KB, image/png)
2024-08-30 06:03 UTC, bdforbes
Details
output of dmesg (varlogdmesg-HTIA.txt,67.42 KB, text/plain)
2024-10-15 01:55 UTC, Guest5
Details
lspci -nnk output (lspci-nnk-O7IQ.txt,4.26 KB, text/plain)
2024-10-15 16:31 UTC, Guest5
Details
dmesg.txt - Kamal (dmesg.txt,69.78 KB, text/plain)
2024-10-17 20:27 UTC, Kamal Davis
Details
lspci -nnk | Kamal (lspci.txt,4.43 KB, text/plain)
2024-10-17 20:27 UTC, Kamal Davis
Details
output from livegui-amd64-20241222T164831Z boot (livegui-amd64-20241222T164831Z.tar,91.50 KB, application/x-tar)
2024-12-30 09:50 UTC, tdr
Details
output from stable iso with modified mesa to include fallback (modifified-mesa.txt.tar,89.00 KB, application/x-tar)
2024-12-30 09:51 UTC, tdr
Details
output from stable iso with nouveau blacklsited (blacklisted-nouveau.tar,96.00 KB, application/x-tar)
2024-12-30 09:52 UTC, tdr
Details
output from stable iso using 6.12.7-gentoo-dist kernel (kernel~arch.tar,97.50 KB, application/x-tar)
2024-12-30 09:57 UTC, tdr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bdforbes 2024-08-30 06:03:09 UTC
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?
[+] Comment 1 immolo 2024-08-30 08:29:26 UTC Comment hidden (obsolete)
Comment 2 immolo 2024-08-30 08:30:29 UTC
Too many tabs open problem....
Comment 3 bdforbes 2024-08-31 05:17:40 UTC
Thanks
Comment 4 François Valenduc 2024-08-31 14:29:56 UTC
The problem still occurs with the versions of 30/8.
Comment 6 François Valenduc 2024-09-11 15:39:19 UTC
The version of 18/8 (https://ftp.belnet.be/pub/rsync.gentoo.org/gentoo/releases/amd64/autobuilds/20240818T143401Z/) is probably the last good version.
Comment 7 Decibels 2024-09-15 16:38:33 UTC
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.
Comment 8 immolo 2024-09-15 20:17:57 UTC
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
Comment 9 Ben Kohler gentoo-dev 2024-09-15 21:06:53 UTC
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.
Comment 10 Guest5 2024-10-15 01:09:00 UTC
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.
Comment 11 Ben Kohler gentoo-dev 2024-10-15 01:15:24 UTC
Please share dmesg output
Comment 12 Guest5 2024-10-15 01:55:26 UTC
Created attachment 905869 [details]
output of dmesg
Comment 13 Ben Kohler gentoo-dev 2024-10-15 14:15:05 UTC
(In reply to Guest5 from comment #12)
> Created attachment 905869 [details]
> output of dmesg

Thanks, can you also share "lspci -nnk" output?
Comment 14 Ben Kohler gentoo-dev 2024-10-15 15:30:53 UTC
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.
Comment 15 Guest5 2024-10-15 16:31:39 UTC
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
Comment 16 Ben Kohler gentoo-dev 2024-10-16 19:05:26 UTC
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
Comment 17 Kamal Davis 2024-10-17 03:35:13 UTC
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.
Comment 18 Ben Kohler gentoo-dev 2024-10-17 14:27:00 UTC
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
Comment 19 Ben Kohler gentoo-dev 2024-10-17 14:41:41 UTC
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.
Comment 20 Kamal Davis 2024-10-17 19:29:33 UTC
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).
Comment 21 Kamal Davis 2024-10-17 20:27:05 UTC
Created attachment 906213 [details]
dmesg.txt - Kamal

uploading my dmesg, lspci to follow
Comment 22 Kamal Davis 2024-10-17 20:27:37 UTC
Created attachment 906214 [details]
lspci -nnk | Kamal

my lspci output
Comment 23 Guest5 2024-11-15 22:43:00 UTC
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".
Comment 24 tdr 2024-12-30 09:44:07 UTC
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
Comment 25 tdr 2024-12-30 09:50:26 UTC
Created attachment 915506 [details]
output from livegui-amd64-20241222T164831Z boot

present stable gui iso
Comment 26 tdr 2024-12-30 09:51:31 UTC
Created attachment 915507 [details]
output from stable iso with modified mesa to include fallback

fallback mesa libs included into iso
Comment 27 tdr 2024-12-30 09:52:27 UTC
Created attachment 915508 [details]
output from stable iso with nouveau blacklsited

stable gui iso with nouveau blacklisted
Comment 28 tdr 2024-12-30 09:57:27 UTC
Created attachment 915509 [details]
output from stable iso using 6.12.7-gentoo-dist kernel

~arch kernel included in iso
Comment 29 tdr 2024-12-30 09:58:18 UTC
$ 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)
Comment 30 immolo 2024-12-30 12:53:09 UTC
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.
Comment 31 anthony 2025-02-12 05:42:49 UTC
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.