Hi, Am Mittwoch, 26. Januar 2022, 16:11:31 CET schrieb cagsm:

On Wed, Jan 26, 2022 at 2:38 PM Matthias Bach wrote:

...

Thanks for figuring out the "nomodeset" workaround! I ran into the same thing and feared it was due to some weirdness of my ancient AMD Athlon(tm) II X2 250 based system or the fact that I don't have systemd in the initrd. "Good" to know that it's some more general issue.

I often run into nodemodeset various grafix and bootup stuff, and I find this very disturbing in the land of linux. I dont know how other than suse distros are doing in terms of quality especially in this area.

I've actually never need to use that, and that system has been running SUSE for ~ 10 years now. FWIW: There is now a bugzilla for this at https://bugzilla.opensuse.org/ show_bug.cgi?id=1195168. Kind Regards, Matthias -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke

On Thu, 27 Jan 2022 18:37:40 +0100 Stephan Hemeier wrote:

See: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142

Reading that, am I misunderstanding? What I think after reading is that: -1- there is a regression bug that causes boot failure for various types of machine -2- there are more or less awkward workarounds for at least some machines -3- there's no plan to release an update -4- it's marked as resolved fixed (despite it being nothing of the kind) Have I misunderstood something?

Stephan

Am Mittwoch, 26. Januar 2022, 13:52:49 CET schrieb cagsm:

...

Hello list dwellers,

some simplistic leap 15.3 system,

just applied tonights kernel update fix

currently installed packages, dunno why after reboot surplus kernels dont get cleaned up btw. used to be in the past?

anyhow:

rpm -aq | grep kernel | sort kernel-default-5.3.18-150300.59.43.1.x86_64 kernel-default-5.3.18-59.40.1.x86_64 kernel-default-extra-5.3.18-150300.59.43.1.x86_64 kernel-default-extra-5.3.18-59.40.1.x86_64 kernel-default-optional-5.3.18-150300.59.43.1.x86_64 kernel-default-optional-5.3.18-59.40.1.x86_64 kernel-firmware-all-20210208-2.4.noarch kernel-firmware-amdgpu-20210208-2.4.noarch kernel-firmware-ath10k-20210208-2.4.noarch kernel-firmware-ath11k-20210208-2.4.noarch kernel-firmware-atheros-20210208-2.4.noarch kernel-firmware-bluetooth-20210208-2.4.noarch kernel-firmware-bnx2-20210208-2.4.noarch kernel-firmware-brcm-20210208-2.4.noarch kernel-firmware-chelsio-20210208-2.4.noarch kernel-firmware-dpaa2-20210208-2.4.noarch kernel-firmware-i915-20210208-2.4.noarch kernel-firmware-intel-20210208-2.4.noarch kernel-firmware-iwlwifi-20210208-2.4.noarch kernel-firmware-liquidio-20210208-2.4.noarch kernel-firmware-marvell-20210208-2.4.noarch kernel-firmware-media-20210208-2.4.noarch kernel-firmware-mediatek-20210208-2.4.noarch kernel-firmware-mellanox-20210208-2.4.noarch kernel-firmware-mwifiex-20210208-2.4.noarch kernel-firmware-network-20210208-2.4.noarch kernel-firmware-nfp-20210208-2.4.noarch kernel-firmware-nvidia-20210208-2.4.noarch kernel-firmware-platform-20210208-2.4.noarch kernel-firmware-prestera-20210208-2.4.noarch kernel-firmware-qlogic-20210208-2.4.noarch kernel-firmware-radeon-20210208-2.4.noarch kernel-firmware-realtek-20210208-2.4.noarch kernel-firmware-serial-20210208-2.4.noarch kernel-firmware-sound-20210208-2.4.noarch kernel-firmware-ti-20210208-2.4.noarch kernel-firmware-ueagle-20210208-2.4.noarch kernel-firmware-usb-network-20210208-2.4.noarch purge-kernels-service-0-8.3.1.noarch

right now only via nomodeset as additional grub2 parameter in that command line there able to boot into this system.

otherwise after grub2 screen and selection or timeout into boot, whole screen gets back, becomes powersaved (monitor says no signal, powersaves itself thereafter)

no ctrl alt del no numlock LED no nothing. no hdd events/LED whole system needs to use the reset button to come back up again into BIOS/POST and grub2 screen again and continuing there only with additional nomodeset parameter.

some elderly amd / amd gpu/chipset based system. worked neatly until a few minutes ago before the kernel update :(

Linux linux 5.3.18-150300.59.43-default #1 SMP Sun Jan 23 19:27:23 UTC 2022 (c76af22) x86_64 x86_64 x86_64 GNU/Linux

01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard Flags: bus master, fast devsel, latency 0, IRQ 10, NUMA node 0 Memory at f0000000 (32-bit, prefetchable) [size=128M] I/O ports at c000 [size=256] Memory at fe9f0000 (32-bit, non-prefetchable) [size=64K] Memory at fe800000 (32-bit, non-prefetchable) [size=1M] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel modules: radeon

01:05.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RS880 HDMI Audio [Radeon HD 4200 Series] Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard Flags: bus master, fast devsel, latency 0, IRQ 19, NUMA node 0 Memory at fe9e8000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel

what now? kernel rpm changelog showd quite a lot of amd/drm fixage and stuff.

anyone able to fix this quickly? thanks. TIA

On Tue, Feb 01, 2022 at 04:16:31PM +0100, cagsm wrote:

On Thu, Jan 27, 2022 at 9:36 PM Dave Howorth wrote:

...

On Thu, 27 Jan 2022 18:37:40 +0100 Stephan Hemeier wrote:

...

https://bugzilla.opensuse.org/show_bug.cgi?id=1195142 Reading that, am I misunderstanding? What I think after reading is that: -1- there is a regression bug that causes boot failure for various types of machine -2- there are more or less awkward workarounds for at least some machines -3- there's no plan to release an update

when will there be a fixed kernel update released? all my systems except for the manual hosed and temp fixed one are nonpatched kernel wise. is leap users always out in the rain? seems we are cannon fodder for the SLES big blokes :( nice shiny distro you built ontop of the suffering open source userbase you have there.

why are we opensuse users this much neglected? when a serious package release gets hosed up, why does it seemingly take ages and a pretty intransparent course as seen from the normal user base to even cope and understand what or if anything will be happening and dealt with to make things work again? i am not talking workarounds or dirty manual hacks. I am talking fixing things and releaseing at least booting kernel packages. thats what they are actually for, arent they? thats a pretty bare minimum thing in my universe to achieve. am I wrong? kernel package? release from a distro vendor? if it aint booting from one release to the next, why not immeditely return back to your desk, but instead continue to pour rotton packages on your userbase to begin with? and why not hurriedly speedily fix it asap on the double? :(

I had the hope of getting a fixed kernel out quickly, but for SLES its slower than just doing openSUSE. Would it help to mark the old as retracted right now? Ciao, Marcus