September 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1175342] zypper purge-kernels fails to work
by bugzilla_noreply＠suse.com 08 Sep '20

08 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175342 https://bugzilla.suse.com/show_bug.cgi?id=1175342#c37 --- Comment #37 from Andreas Schwab <schwab(a)suse.de> --- Nothing has changed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1175342] zypper purge-kernels fails to work
by bugzilla_noreply＠suse.com 08 Sep '20

08 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175342 https://bugzilla.suse.com/show_bug.cgi?id=1175342#c36 --- Comment #36 from Benjamin Zeller <bzeller(a)suse.com> --- (In reply to Andreas Schwab from comment #35) > Still not fixed. Care to share more details? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1175342] zypper purge-kernels fails to work
by bugzilla_noreply＠suse.com 08 Sep '20

08 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1175342 https://bugzilla.suse.com/show_bug.cgi?id=1175342#c35 Andreas Schwab <schwab(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #35 from Andreas Schwab <schwab(a)suse.de> --- Still not fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1167927] kernel crash trace - drm
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1167927 James Moe <jimoe(a)sohnen-moe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jimoe@sohnen-moe. | |com) | -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1167927] kernel crash trace - drm
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1167927 https://bugzilla.suse.com/show_bug.cgi?id=1167927#c3 --- Comment #3 from James Moe <jimoe(a)sohnen-moe.com> --- (A spurious email change prevented notification of receiving this message.) Thanks. I have not seen this error again. AFAICT the system is running the nouveau driver now. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1175626] Recent update run on August 21, 2020 kills bootloader
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175626 http://bugzilla.opensuse.org/show_bug.cgi?id=1175626#c62 --- Comment #62 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to John Shaw from comment #61) > From what I can tell, it looks like the driver went from 450.57 to 450.66 > which would be a version change. Ok, so my theory is void again :-/ > The current state of the machine (which I need for work, so I can't afford > to screw it up too much;) is that if I enable SecureBoot, it DOES now flash > what is likely a MOK message (what else could it be?). Sometimes the BIOS itself prints something on the screen. MokManager output would typically be blue color, and centered on the screen. > This is almost > certainly due to the nVidia driver. However, flash is the operative word. I > cannot read it and I cannot catch it with a key press. Sure enough, that looks like a malfunction of MokManager. But only on your system. Strange. > I tried a couple of > times, but the message is up for maybe 1/10th of a second. What this thing > needs is to pause for a few seconds. The boot process at least gets past > this and drops into grub. If I boot suse, it fails to load the nvidia > driver. I tried to reinstall the driver, but I can't find a way to get MOK > to enroll it. Be careful with "reinstalling", as noted above that procedure is a bit flawed in the current release. It's better to uninstall and install again. Please provide output of mokutil --list-enrolled, mokutil --list-new, mokutil --list-delete. > Booting with SecureBoot disabled still works. > > I could not boot the shellx86.efi from my /boot/efi partition. The bios > gives the option to boot it from a USB drive, so I guess I can try that. As > you suggest, I could try and add a boot entry with efibootmgr, but the USB > option is safer. Sorry that this is such a hassle for you. Using efibootmgr for this is actually not so dangerous because it will create a new boot entry, and if that one can't be booted, the EFI bootloader will fall back to the next working one. But I can understand that you're wary after your recent experience. I'd do it roughly like this (note that you need to adapt disk (-d), partition (-p) and path (-l)): > efibootmgr -c -L 'UEFI Shell' -d /dev/sda -p 1 -l '\EFI\shell\shellx64.efi' -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1175626] Recent update run on August 21, 2020 kills bootloader
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175626 http://bugzilla.opensuse.org/show_bug.cgi?id=1175626#c61 --- Comment #61 from John Shaw <johngshaw(a)twc.com> --- (In reply to Martin Wilck from comment #60) > (In reply to John Shaw from comment #59) > > Unfortunately I can't really confirm what the exact version was for the > > nVidia update that came through. I tried hunting thoughout the saved > > snapshots, but only succeeded in hanging the yast snapshot tool after > > looking for differences between saved pairs. This is the first time that has > > happened, it may be that there were a LOT of differences in the pair I was > > examining. The current version for the nVidia driver is 450.66, but I doubt > > that helps much. > > You chose quite a complex method to figure this out ;-) > I'd just run "grep -i nvidia /var/log/zypp/history"; possibly prepend > /.snapshots/$X/snapshot with the snapshot where the problem first occured. > > > I finally found compiled efi shell (from the Arch Linux repos) and copied it > > to by UEFI partition. I should be able to get into to from the BIOS. I can > > try to boot the opensusi shim.efi file and see what happens. > > Thanks a lot for your cooperation! >From what I can tell, it looks like the driver went from 450.57 to 450.66 which would be a version change. The current state of the machine (which I need for work, so I can't afford to screw it up too much;) is that if I enable SecureBoot, it DOES now flash what is likely a MOK message (what else could it be?). This is almost certainly due to the nVidia driver. However, flash is the operative word. I cannot read it and I cannot catch it with a key press. I tried a couple of times, but the message is up for maybe 1/10th of a second. What this thing needs is to pause for a few seconds. The boot process at least gets past this and drops into grub. If I boot suse, it fails to load the nvidia driver. I tried to reinstall the driver, but I can't find a way to get MOK to enroll it. Booting with SecureBoot disabled still works. I could not boot the shellx86.efi from my /boot/efi partition. The bios gives the option to boot it from a USB drive, so I guess I can try that. As you suggest, I could try and add a boot entry with efibootmgr, but the USB option is safer. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1175626] Recent update run on August 21, 2020 kills bootloader
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175626 http://bugzilla.opensuse.org/show_bug.cgi?id=1175626#c60 --- Comment #60 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to John Shaw from comment #59) > Unfortunately I can't really confirm what the exact version was for the > nVidia update that came through. I tried hunting thoughout the saved > snapshots, but only succeeded in hanging the yast snapshot tool after > looking for differences between saved pairs. This is the first time that has > happened, it may be that there were a LOT of differences in the pair I was > examining. The current version for the nVidia driver is 450.66, but I doubt > that helps much. You chose quite a complex method to figure this out ;-) I'd just run "grep -i nvidia /var/log/zypp/history"; possibly prepend /.snapshots/$X/snapshot with the snapshot where the problem first occured. > I finally found compiled efi shell (from the Arch Linux repos) and copied it > to by UEFI partition. I should be able to get into to from the BIOS. I can > try to boot the opensusi shim.efi file and see what happens. Thanks a lot for your cooperation! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1175626] Recent update run on August 21, 2020 kills bootloader
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1175626 http://bugzilla.opensuse.org/show_bug.cgi?id=1175626#c59 --- Comment #59 from John Shaw <johngshaw(a)twc.com> --- (In reply to Martin Wilck from comment #57) > (In reply to John Shaw from comment #43) > > > This seemed to be working on my machine after the last round of grub2 > > updates went through, then this morning a new nVidia driver update came > > (along with about 20 other updates). On reboot with SecureBoot enabled, the > > machine hung after post with a black screen. I rebooted with SecureBoot > > disabled (ie, selected OtherOS in the ASUS bios), and it brought up the MOK > > Manager. However, unlike before the options are now different. There is no > > "enrole MOK", just: Continue, Reset MOK, Delete MOK, and enrole key and > > enrole hash from disk. > > I think I understand this now, at least partially. The explanation is > similar to what I wrote in comment 48. Can you confirm that the *version* of > the Nvidia driver was different, with only the *release* differing? Because > the driver package was using only the *version* (and not the release) in the > certificate file name, the package update would create both an import and a > deletion request for the same (new!) key at the same time, rather than a > delete request for the old and an import request for the new one. Not sure > how MokManager would deal with that, but your comment shows that it offered > the key only for deletion. The latest Nvidia package fixes this by adding > the release to the certificate file name. > > If it's only that, you should be able to recover from the problem by booting > into a non-graphical environment, uninstalling the nvidia-gfx0$X package, > and installing it again. > > I don't understand why any of this would cause your GRUB menu not to be > shown. Normally these keys wouldn't be used until user space tries to load > the nvidia driver. By that time, you should be past grub and past lots of > boot messages from the kernel. The only explanation I have for that is that > mokmanager might crash while trying to deal with the "contradictory" mok > requests. > > (In reply to John Shaw from comment #37) > > (In reply to Martin Wilck from comment #36) > > > The question is if the BIOS fails to verify the shim, or shim fails to > > > verify any of the follow-up binaries. Can you check this e.g. with the UEFI > > > shell? > > > > I don't know how to check this in the UEFI shell. Can you explain? > > If you don't have an existing UEFI shell boot entry already, grab one. See > e.g. > > > https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#… > > Next you need to copy this to your EFI boot partition, and find a way to > make your BIOS boot it. Either the BIOS has a way to boot a specified EFI > binary directly, or you could use efibootmgr to craft a suitable entry for > it. > > Once in the shell, you can move around and run commands a bit like on good > old DOS. You may have to enter a "drive" first, which would look like > "fs0:". The "map" command can be used to see drives that the shell has > recognized. The test would look roughly like this: > > > fs0: > > cd \EFI\BOOT > > bootx64.efi # or whatever else you want to boot > > The advantage is that you would see some error messages in this environment, > e.g. if the binary's signature can't be verified by the BIOS. Unfortunately I can't really confirm what the exact version was for the nVidia update that came through. I tried hunting thoughout the saved snapshots, but only succeeded in hanging the yast snapshot tool after looking for differences between saved pairs. This is the first time that has happened, it may be that there were a LOT of differences in the pair I was examining. The current version for the nVidia driver is 450.66, but I doubt that helps much. I finally found compiled efi shell (from the Arch Linux repos) and copied it to by UEFI partition. I should be able to get into to from the BIOS. I can try to boot the opensusi shim.efi file and see what happens. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[kernel-bugs] [Bug 1176233] Unable to install nvidia driver 450.66
by bugzilla_noreply＠suse.com 07 Sep '20

07 Sep '20

https://bugzilla.suse.com/show_bug.cgi?id=1176233 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Assignee|kernel-bugs(a)opensuse.org |sndirsch(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0