Bugzilla – Bug 1101711
Can not install Leap 15.0 due system freeze
Last modified: 2020-10-05 15:59:21 UTC
Created attachment 777337 [details] output of hwinfo the system does freeze if I try to boot withe default kernel as well as with secure boot options. In last case the freeze happens at first screen of yast where I do not have mouse nore keyboard. This system is a Tuxedo (TUXEDO N15_17RD,RD2) and I'm using fo Leap 42.3 resume=/dev/nvme0n1p1 splash=silent i915.preliminary_hw_support=1 rcutree.rcu_idle_gp_delay=1 plymouth.enable=0 systemd.show_status=true acpi_os_name=Linux acpi_backlight=vendor "acpi_osi=!Windows 2012" usbcore.autosuspend=-1 acpi=force acpi_sleep=s3_bios libata.force=5.00:noncq elevator=bfq video=DP-0:1920x1080@60 I've tried to add some of the options above i915.preliminary_hw_support=1 rcutree.rcu_idle_gp_delay=1 acpi_os_name=Linux "acpi_osi=!Windows 2012" usbcore.autosuspend=-1 acpi=force acpi_sleep=s3_bios libata.force=5.00:noncq video=DP-0:1920x1080@60 but this had not worked at all.
could be belong to Kernel instead of Installation but it happens at installation
I've seen quite a number of reports where leap 15 freezes trying to load the nouveau driver. Does 'nomodeset' help? I'll move the bug to kernel.
Yes, nouveau module on Leap 15.0 kernel is buggy, especially for Intel + Nouveau hybrid graphics. It's already mentioned in the release notes. The update kernel (maybe not yet released) already contains the fix. So please install / upgrade with nomodeset option, and remove it after updating to the latest kernel in OBS Kernel:openSUSE-15.0 repo.
(In reply to Takashi Iwai from comment #4) > Yes, nouveau module on Leap 15.0 kernel is buggy, especially for Intel + > Nouveau hybrid graphics. It's already mentioned in the release notes. > > The update kernel (maybe not yet released) already contains the fix. So > please install / upgrade with nomodeset option, and remove it after updating > to the latest kernel in OBS Kernel:openSUSE-15.0 repo. Indeed nomodeset helps a lot yes. Nevertheless without latest haveged from Factory booting is slow at switch root. Btw: it is *not* slow with the older kernel from Leap 42.3 ... My guess is that newer kernel do cause lesser entropy then older kernels. Also I had to reset the passwords for root and the users in rescue mode as I run into the problem that the encrypted password for root had not worked in emergency mode (md5???). Also I run into the problem that the r8169 does not work and never had worked with my book and without plugged ethernet it is not possible to install r8168 from packman. Last but not least I lost the louder/lesser keys (Fn+F6 and Fn+F5) whereas backlight for screen and keyboard do work. I do not use nouveau but nvidia and this works as usual with xrand in Xsetup to switch from Intel to Nvidia.
(In reply to Dr. Werner Fink from comment #5) > Last but not least I lost the louder/lesser keys (Fn+F6 > and Fn+F5) whereas backlight for screen and keyboard do work. Please check whether it's a kernel problem or not. e.g. run evtest on Linux console (VT1), and see whether the audio key emits an event. If the key event is generated, it's an issue in the desktop. If no key event is generated on any input devices, it's a kernel regression.
(In reply to Takashi Iwai from comment #6) > (In reply to Dr. Werner Fink from comment #5) > > Last but not least I lost the louder/lesser keys (Fn+F6 > > and Fn+F5) whereas backlight for screen and keyboard do work. > > Please check whether it's a kernel problem or not. e.g. run evtest on Linux > console (VT1), and see whether the audio key emits an event. > If the key event is generated, it's an issue in the desktop. If no key > event is generated on any input devices, it's a kernel regression. Seems to be code 114 and 115 Testing ... (interrupt to exit) Event: time 1532448315.715973, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1c Event: time 1532448315.715973, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0 Event: time 1532448315.715973, -------------- SYN_REPORT ------------ Event: time 1532448321.126268, type 4 (EV_MSC), code 4 (MSC_SCAN), value ae Event: time 1532448321.126268, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1532448321.126268, -------------- SYN_REPORT ------------ Event: time 1532448321.168896, type 4 (EV_MSC), code 4 (MSC_SCAN), value ae Event: time 1532448321.168896, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1532448321.168896, -------------- SYN_REPORT ------------ Event: time 1532448322.396439, type 4 (EV_MSC), code 4 (MSC_SCAN), value b0 Event: time 1532448322.396439, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1 Event: time 1532448322.396439, -------------- SYN_REPORT ------------ Event: time 1532448322.448322, type 4 (EV_MSC), code 4 (MSC_SCAN), value b0 Event: time 1532448322.448322, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0 Event: time 1532448322.448322, -------------- SYN_REPORT ------------ Event: time 1532448324.093792, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3e Event: time 1532448324.093792, type 1 (EV_KEY), code 62 (KEY_F4), value 1 Event: time 1532448324.093792, -------------- SYN_REPORT ------------ Event: time 1532448324.169310, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3e Event: time 1532448324.169310, type 1 (EV_KEY), code 62 (KEY_F4), value 0 Event: time 1532448324.169310, -------------- SYN_REPORT ------------ Event: time 1532448324.748597, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3f Event: time 1532448324.748597, type 1 (EV_KEY), code 63 (KEY_F5), value 1 Event: time 1532448324.748597, -------------- SYN_REPORT ------------ Event: time 1532448324.813787, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3f Event: time 1532448324.813787, type 1 (EV_KEY), code 63 (KEY_F5), value 0
(In reply to Dr. Werner Fink from comment #7) > (In reply to Takashi Iwai from comment #6) > > (In reply to Dr. Werner Fink from comment #5) > > > Last but not least I lost the louder/lesser keys (Fn+F6 > > > and Fn+F5) whereas backlight for screen and keyboard do work. > > > > Please check whether it's a kernel problem or not. e.g. run evtest on Linux > > console (VT1), and see whether the audio key emits an event. > > If the key event is generated, it's an issue in the desktop. If no key > > event is generated on any input devices, it's a kernel regression. > > Seems to be code 114 and 115 Then please report this specific one to a different bug report for the desktop. It's neither kernel nor installer problem, per se.
Hmm ... X seems to know KeyPress event, serial 36, synthetic NO, window 0x4e00001, root 0x4dc, subw 0x4e00002, time 55657086, (53,59), root:(1724,181), state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x4e00001, root 0x4dc, subw 0x4e00002, time 55657163, (53,59), root:(1724,181), state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 36, synthetic NO, window 0x4e00001, root 0x4dc, subw 0x4e00002, time 55658659, (53,59), root:(1724,181), state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x4e00001, root 0x4dc, subw 0x4e00002, time 55658705, (53,59), root:(1724,181), state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
The working function keys (Fn+FX) are not seen by evtest nor xev therefore I guess the kernel does control e.g. the backlight in direct way?
(In reply to Dr. Werner Fink from comment #9) > Hmm ... X seems to know It's desktop-envrionment specific issue, not a lowlevel system like X or kernel. Usually some desktop daemon catches such events and handles properly. In the case of XFCE, e.g. it's xfce4-panel-plugin-pulse or such.
(In reply to Dr. Werner Fink from comment #10) > The working function keys (Fn+FX) are not seen by evtest nor xev therefore > I guess the kernel does control e.g. the backlight in direct way? It's possible that kernel handles via ACPI backlight event, but it's pretty rare nowadays. Are you sure that you've tested all event devices via evtest? (xev is often difficult as the user daemon may take the even already away.) But, since the backlight control seems working on your system, it's not that important...