That tweak wouldn’t do much for me now as 4.18.5 is already gone. Would have to install a custom kernel from a separate repository which could break stuff and put my system at risk. I’m stuck until the admins find a solution.
I doubt a login manager would be causing this, especially since I cannot either restart X (control + alt + 2 x backspace) nor switch to another runlevel (control + alt + fN). SDDM is the default of openSUSE and I’d rather not mess with stuff I haven’t used before unless absolutely necessary, especially since this possibility feels very unlikely. I have however enabled auto-login for my user account and ran a test session… exact same results, skipping the login managed doesn’t change anything.
Until there’s more news on this issue, I wanted to make a slightly odd request which might help in case I need a Kernel that still boots with amdgpu. If you are an user that:
Uses openSUSE Tumbleweed (not Leap).
Installs their Kernel from the official repository (openSUSE-OSS, not third parties).
Did not tinker with the Kernel compilation parameters (Kernel is compiled using the defaults).
Still has Kernel 4.18.5 installed.
Could you please pack your /boot directory into a zip or tar.gz archive and send it to me? You should only need to attach the files with the kernel version in their name: config--default, initrd--default, symtypes--default, sysctl.conf--default, System.map--default, vmlinux--default.gz, vmlinuz-*-default. I’d need version 4.18.5 obviously.
The issue is that, the update process erased 4.18.5 and the official repository no longer has it either, so there’s no way for me to get it back on the affected machine. I’m stuck on 4.19.2 which so far works but only on the radeon driver. I’d feel better prepared if I could have the old one back just in case I need amdgpu for a given task until this is solved. I should be able to edit grub.cfg and easily integrate it back into my /boot directory.
Nice to hear others are lucky at least. Nothing changes for me with the latest Tumbleweed snapshot (20181122).
Thanks… I’ll keep this possibility in mind in case of an emergency. I did not know older snapshots were still maintained on the openSUSE servers, that’s very handy. Snapshot 20181112 is indeed the last to have had Kernel 4.18.5 so I’d use:
tumbleweed switch 20181122
In the meantime: Was the openSUSE crew able to officially confirm this issue so far, and is there an ETA for when the latest snapshot will fix it? I’m hoping to at least hear that my issue is known and there’s a plan to approach it.
Starting with kernel 4.19.1 and continuing with 4.19.5 (snapshot 20181205) boot takes 3 to 10 minutes of screen flashing and the “loading” squared are not where they usually are. Then everything is normal. When I could boot from 4.18.x the problem disappears. When I restore a 6 month old backup copy it works until I zypper dup.
NVIDIA GTX 1050Ti
ASUS m5a99fx mobo
I may install the NVIDIA driver “the hard way” thinking that may solve it.
Nothing has changed here with snapshot 20181206 so mine is a different problem. Disappointed that such a major issue can go on for so long, without the problem having even been confirmed or pinpointed yet.
Do I simply add a 3 as a parameter? nomodeset I haven’t yet tried… I just type that into the kernel boot parameters correct? amdgpu.dc=0 I have tried, it only changes what gets frozen on the screen… see a few posts above on that. plymouth.enable=0 too, no difference.
When I add 3 after Linux … QUIET 3 it starts with the three little progress indicator boxes offset from normal, but does enter Runlevel 3 just fine.
Login as root OK #startx <----starts OK (runlevel 5 ?)
Logout <— back to runlevel 3 as root #
I want to get back into runlevel 5 as user …without the 10 minutes of a runlevel 5 boot
So, could it be something between runlevel 3 and startx?