Leap 15.3 latest kernel update gibts bootup freeze on amd gpu based - nomodeset needed to work again
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
Hi, Am Mittwoch, 26. Januar 2022, 13:52:49 CET schrieb cagsm:
some simplistic leap 15.3 system,
just applied tonights kernel update fix
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)
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. Mine also is an Asus board with an AMD on-board graphic: 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] 01:05.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RS780 HDMI Audio [Radeon 3000/3100 / HD 3200/3300] One thing I noted is that the when booting with "nomodeset" the console complains about the following: [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module! Did you already open a bug on bugzilla.opensuse.org? Seems like a general regression. 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 Wed, Jan 26, 2022 at 2:38 PM Matthias Bach <marix@marix.org> 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. as a direct result I simply find no way to fully switch over to linux as a platform, coming mostly from windows myself. I run linux for some simple servers and stuff, but nowhere near desktop usage. when I look at these bugs it really gives me the chill and makes me frustrated and deters me from further investing into linux :( I just dont understand how simple vga or graphics stuff in the age of vesa or aged and seasoned graphics hardware can express this level of bugs and trouble :(
Mine also is an Asus board with an AMD on-board graphic: 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] 01:05.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RS780 HDMI Audio [Radeon 3000/3100 / HD 3200/3300] One thing I noted is that the when booting with "nomodeset" the console complains about the following: [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
yes Im seeing those lines as well. I mostly remember such lines from when using simle linux based distributions such as clonezilla or gparted for basic recovery and such stuff. I guess those distros want or need to have the possiblity for the user to absolutely boot the systems no matter what and dont want to break down due to fancy stuff such as graphics drivers and dealing with hardware too much. never researched into what this UMS and stuff meant in detail.
Did you already open a bug on bugzilla.opensuse.org? Seems like a general regression.
sorry, no. ty. tia.
Hi, Am Mittwoch, 26. Januar 2022, 16:11:31 CET schrieb cagsm:
On Wed, Jan 26, 2022 at 2:38 PM Matthias Bach <marix@marix.org> 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 1/26/22 10:11, cagsm 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
On Wed, Jan 26, 2022 at 2:38 PM Matthias Bach <marix@marix.org> wrote: than suse distros are doing in terms of quality especially in this area. as a direct result I simply find no way to fully switch over to linux as a platform, coming mostly from windows myself. I run linux for some simple servers and stuff, but nowhere near desktop usage. when I look at these bugs it really gives me the chill and makes me frustrated and deters me from further investing into linux :( I just dont understand how simple vga or graphics stuff in the age of vesa or aged and seasoned graphics hardware can express this level of bugs and trouble :(
Mine also is an Asus board with an AMD on-board graphic: 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] 01:05.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RS780 HDMI Audio [Radeon 3000/3100 / HD 3200/3300] One thing I noted is that the when booting with "nomodeset" the console complains about the following: [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module! yes Im seeing those lines as well. I mostly remember such lines from when using simle linux based distributions such as clonezilla or gparted for basic recovery and such stuff. I guess those distros want or need to have the possiblity for the user to absolutely boot the systems no matter what and dont want to break down due to fancy stuff such as graphics drivers and dealing with hardware too much.
never researched into what this UMS and stuff meant in detail.
Did you already open a bug on bugzilla.opensuse.org? Seems like a general regression. sorry, no. ty. tia.
/etc/zypp/zypp.conf Use the 'multiversion = provides:multiversion(kernel)' and 'multiversion.kernels = ' user-defined parameters to configure multiple kernel versions in parallel. Each kernel with have a corresponding grub2 entry. If a kernel update breaks something, boot into a previous kernel. --dg 15.3/Plasma
cagsm composed on 2022-01-26 13:52 (UTC+0100):
right now only via nomodeset as additional grub2 parameter in that command line there able to boot into this system. ... 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]) ... what now?
Wait for someone to provide a bug fix, and use older kernel in the mean time. https://bugzilla.opensuse.org/show_bug.cgi?id=1195168 -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
See: https://bugzilla.opensuse.org/show_bug.cgi?id=1195142 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 Thu, 27 Jan 2022 18:37:40 +0100 Stephan Hemeier <Sauerlandlinux@gmx.de> wrote:
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 Thu, Jan 27, 2022 at 9:36 PM Dave Howorth <dave@howorth.org.uk> wrote:
On Thu, 27 Jan 2022 18:37:40 +0100 Stephan Hemeier <Sauerlandlinux@gmx.de> 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? :( ty
On Tue, Feb 01, 2022 at 04:16:31PM +0100, cagsm wrote:
On Thu, Jan 27, 2022 at 9:36 PM Dave Howorth <dave@howorth.org.uk> wrote:
On Thu, 27 Jan 2022 18:37:40 +0100 Stephan Hemeier <Sauerlandlinux@gmx.de> 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
Marcus Meissner composed on 2022-02-01 16:24 (UTC+0100):
Would it help to mark the old as retracted right now?
Will that help anyone who installed with online repos enabled since it hit the mirrors? It should have been retracted days ago. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
participants (7)
-
cagsm -
Dave Howorth -
DennisG -
Felix Miata -
Marcus Meissner -
Matthias Bach -
Stephan Hemeier