JoshStrobl
display-manager.service did not fix it
amdgpu.conf did not fix it
amdgpu+radeon.conf did not fix it
radeon.conf only, at first i thought it fixed it, but rebooting again twice and it didnt work (gdm would always load once in a while even without any fixes)
i wont be around to test any other ideas you might have tonight

      Alright, this is super heavy-handed, but I'd forced dracut to pull in all of the major KMS drivers (and apparently AMD firmware) when building the initrd. This is similar to Early KMS on distros where the initrd is built on each update. In theory this forces the KMS drivers to be ready way before GDM will even try to start an xserver. I've tested on AMD Vega FE with LightDM.

      Here's a test kernel for AMD/Intel (it will not work with Nvidia proprietary) for you folks to try: http://getsol.us/sources/linux-current-5.10.7-169-1-x86_64.eopkg

        DataDrake @JoshStrobl
        this works, 3 reboots to be sure

        incidently also it feels like i have to enter my decryption pw at a later stage, also the fonts are much smaller at the deecryption stage, and looks much better, previously it was rather ugly with huge fonts and the disk uuid spiling over 2 lines etc

            8 days later

            so 5.10.9
            everything works, gmd and all, but theres slightly weird behaviour, first the old decryption screen appears, with big fonts, then screen goes blank for a second (and gpu drivers are loaded i guess, cos i the gpu fans spin down at this point) and the decryption screen appears with small fonts. no problem, i just thought something went wrong at first

            Following yesterday's update (2021-01-23), my laptop boots to a black screen and never reaches the greeter. I'm using both current kernel and nvidia driver. Rebooting and switching to the previous kernel (5.10.7) with the bootloader allows me to login normally.

            Below are my system specs (from inxi -CG):

            CPU:       Info: Dual Core model: Intel Core i7-7500U bits: 64 type: MT MCP L2 cache: 4 MiB 
           Speed: 3500 MHz min/max: 400/3500 MHz Core speeds (MHz): 1: 3500 2: 3500 3: 3500 4: 3500 
Graphics:  Device-1: Intel HD Graphics 620 driver: i915 v: kernel 
           Device-2: NVIDIA GM107M [GeForce GTX 950M] driver: nvidia v: 460.32.03 
           Device-3: Realtek Integrated Camera type: USB driver: uvcvideo 
           Display: x11 server: X.Org 1.20.10 driver: modesetting,nvidia resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce GTX 950M/PCIe/SSE2 v: 4.6.0 NVIDIA 460.32.03

            Here is the sudo journalctl -b -e from my latest failed boot:

            If any additional info is needed to help troubleshoot this issue, please let me know! Thanks in advance for your help 🙂

            6 days later

            The same problem I reported last persists with the new 5.10.11 current kernel. So now neither the new and fallback (previous) current kernel can boot to a GUI for me.

            I tried installing the LTS kernel as a backup while things get sorted out with the current branch, but it isn't able to boot to a GUI either. The behavior before the black screen is slightly different however, so I suspect the underlying issues with the 2 kernel branches are different.

            I know this is not recommended, but does anyone know how to rollback to a specific kernel version of a branch? I tried to rollback eopkg updates, but a package recently removed from the repo causes the whole process to fail.

            Since this is my only computer, and Solus is my main OS with which I do all my work remotely at the moment, I'm a bit desperate for a quick fix to this. Thanks in advance for the help!

              I too had this issue with the last kernel update, and rolled myself back to 5.09 from 5.10, but ran the command to make 5.09 current. So today when I ran the update from yesterday, it started doing the same thing, locking/looping at the desktop picture, but no other items like the task manager etc load. Rebooted and went into grub where it showed me using 10.11 now with my 10.09 with I reverted to and it loaded just fine. So the kernel update on Jan 29 did not fix this for me.

              I am running KDE/Solus with an Nvida 1050ti video card.

              nathanpainchaud

              While the old packages are still available, and until something else breaks because of incompatibilities, you could install the following eopkgs from the server:

              http://mirrors.rit.edu/solus/packages/shannon/n/nvidia-glx-driver/nvidia-glx-driver-common-460.32.03-364-1-x86_64.eopkg
              http://mirrors.rit.edu/solus/packages/shannon/n/nvidia-glx-driver/nvidia-glx-driver-current-460.32.03-364-1-x86_64.eopkg
              http://mirrors.rit.edu/solus/packages/shannon/n/nvidia-glx-driver/nvidia-glx-driver-32bit-460.32.03-364-1-x86_64.eopkg
              http://mirrors.rit.edu/solus/packages/shannon/l/linux-current/linux-current-5.10.7-168-1-x86_64.eopkg

              sudo eopkg it [URL] works, but I'm not sure if you can do all at once.

              Note that these packages will be purged from the server after a while, and you might run into other issues before that.
              Also if you're using stuff like VirtualBox you'd also have to install older package versions compatible with this kernel.

                  Staudey I didn't realize you could use URLs to install packages. I understand that it's not the recommended way to proceed, but that's good to know!

                  Also, for anyone experiencing the same issue, Staudey identified the problem for me over on the dev tracker. I set the nvidia-drm.modeset=1 kernel parameter (in /etc/kernel/cmdline.d/50-nvidia-drm.conf) to fix common screen tearing issues with hybrid Nvidia laptops. Setting it to nvidia-drm.modeset=0 allows me to boot to a GUI again!

                  However, I had this parameter set ever since I installed on my laptop nearly 3 years ago, so it seems to be a regression of the last few current kernel releases. I hope these get fixed soon so that I can fix screen tearing issues again. Although I'll gladly take those screen tearing issues over no GUI at all 😛

                      nathanpainchaud Glad to hear that my hunch was right after all (totally missed your second edit on the dev tracker 🙂)
                      Too bad that this parameter doesn't work atm. The latest nvidia driver release (460.39) restores

                      functionality of some features, including runtime power management, hotplugging audio-capable display devices, and S0ix-based system suspend, with recent kernels such as Linux 5.10.

                      but no mention of modeset. And if it still didn't work after Friday's updates, then I guess it also wasn't silently fixed with that release. At least they seem to be aware of issues with kernel 5.10.