openSUSE Bugs June 2023

bugs@lists.opensuse.org

1 participants
185 discussions

[Bug 1212874] New: External Monitor on USB-C Docking station AMD Graphics
by bugzilla_noreply＠suse.com 13 Sep '23

13 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1212874 Bug ID: 1212874 Summary: External Monitor on USB-C Docking station AMD Graphics Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: j.g.joseph4884(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Just reinstalled OpenSuse Tumbleweed to see if my install was impacting the external monitor connection on my docking station - Still occurs; Hardware * Laptop - Thinkoad E595 | AMD Ryzen 5 * Docking Station - Lenovo 40AS0090US * External Monitors - 1 High Refresh Rate 1080p (Displayport) & 1 UltraWide 1080p (HDMI) On Windows - The Laptop displays on all monitors with no issues at the highest refresh rates for both monitors Been having issues since the start of Kernel 6.0 where I cannot use both my external monitors with my laptop at 1080p. When I keep the laptop plugged into the docking station and let the device sleep, it crashes before it can fully sleep with the cursor still slightly visible on a dark background. If I keep the laptop plugged into the docking station on startup, it crashes right when the loading circle starts to spin above the Tumbleweed logo. Let me know what commands I need to enter to output info to assist the kernel developers -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1212835] New: make modules_install fails with kmod-30-4.1
by bugzilla_noreply＠suse.com 11 Sep '23

11 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1212835 Bug ID: 1212835 Summary: make modules_install fails with kmod-30-4.1 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: msuchanek(a)suse.com Reporter: ptesarik(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- With the usrmerge patches, depmod now accesses $base/usr/lib/modules instead of $base/lib/modules. Unfortunately, scripts/depmod.sh in the kernel sources cannot cope with that and fails with a slightly confusing message: depmod: ERROR: could not open directory /srv/research/dynswiotlb-9p/usr/lib/modules/99.98.6.5.0-devel+: No such file or directory I can see how this is fixed for RPM builds (https://github.com/SUSE/kernel-source/commit/da84579e78f4c4efa5b3b910484fda…), but I can no longer run "make modules_install" from the expanded kernel tree. -- You are receiving this mail because: You are on the CC list for the bug.

1 43

[Bug 1212839] New: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT
by bugzilla_noreply＠suse.com 04 Sep '23

04 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1212839 Bug ID: 1212839 Summary: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- LTP test cve-2021-22555 setsockopt08.c fails with ENOENT [1], but it expects EINVAL on mostly all archs on Tumbleweed (all but s390x, i.e. aarch64, ppc64le, x86_64 and x86_64 compiled as 32bit). The test has been failing for very long time (our history goes to 6.3.2 20230517, but it's failing on my VM with 6.2.12-1-default 20230502). When test run more times (200x with -i200 [3]) it fails only on first time, the rest happily have EINVAL. And indeed, when verifying manually on VM, only first run fails dmesg on affected archs contains: [ 1514.789118][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.792200][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.795209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.798209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.801190][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.804092][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.807159][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.810210][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.813257][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.816227][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 But when running manually I see on first (failing): [ 208.455124] bpfilter: Loaded bpfilter_umh pid 1223 [ 208.456650] Started bpfilter (this is also in openQA jobs, but earlier, triggered by setsockopt03.c, which runs earlier). And x_tables run is reported on later (successful run): [ 221.292549] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 => Maybe there is a problem with loading x_tables on these 3 archs Interestingly x_tables is loaded on all archs, including s390x (which does not fail) and the same dmesg [4] FYI we stop and disable firewall in openQA install_ltp job (this qcow is then used for LTP tests) [5]: systemctl --no-pager disable firewalld Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service". Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service". systemctl --no-pager stop firewalld [1] https://openqa.opensuse.org/tests/3390125#step/setsockopt08/7 [2] https://github.com/linux-test-project/ltp/blob/a564d3e1672e9cd7ac302d597ffa… [3] https://openqa.opensuse.org/tests/3391862#step/cve-2021-22555/7 [4] https://openqa.opensuse.org/tests/3380876/file/shutdown_ltp-dmesg.txt [5] https://openqa.opensuse.org/tests/3391842/file/serial_terminal.txt -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1212853] New: GRUB2 asking for passphrase twice again
by bugzilla_noreply＠suse.com 18 Aug '23

18 Aug '23

https://bugzilla.suse.com/show_bug.cgi?id=1212853 Bug ID: 1212853 Summary: GRUB2 asking for passphrase twice again Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: eyadlorenzo(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Yesterday I reinstalled my Tumbleweed system, with crypted root and crypted swap. I now get again asked twice for my passphrase. I could follow what described in https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the…, but last time I installed Tumbleweed there was no need (see https://bugzilla.opensuse.org/show_bug.cgi?id=1206710) for details. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1212906] New: fanotify23 randomly fails on Tumbleweed when run more times
by bugzilla_noreply＠suse.com 14 Aug '23

14 Aug '23

https://bugzilla.suse.com/show_bug.cgi?id=1212906 Bug ID: 1212906 Summary: fanotify23 randomly fails on Tumbleweed when run more times Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jack(a)suse.com Reporter: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- LTP fanotify23 test (test for FAN_MARK_EVICTABLE from 5.19) fails, when run more times. I tested it on all archs on the current Tumbleweed kernel [2], it fails everywhere. It also fails when tested on VM with older 6.2.8-1-default kernel (where it mostly fails, I guess the behavior is the same on all recent version): # /opt/ltp/testcases/bin/fanotify23 -i5 tst_device.c:97: TINFO: Found free device 0 '/dev/loop0' tst_test.c:1094: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts='' mke2fs 1.46.5 (30-Dec-2021) tst_test.c:1560: TINFO: Timeout per run is 0h 00m 30s fanotify23.c:112: TPASS: FAN_MARK_ADD failed with EEXIST as expected when trying to downgrade to evictable mark fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after empty mask fanotify23.c:156: TPASS: Got no events as expected fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after drop_caches fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:112: TPASS: FAN_MARK_ADD failed with EEXIST as expected when trying to downgrade to evictable mark fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after empty mask fanotify23.c:156: TPASS: Got no events as expected fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after drop_caches fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:112: TPASS: FAN_MARK_ADD failed with EEXIST as expected when trying to downgrade to evictable mark fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after empty mask fanotify23.c:156: TPASS: Got no events as expected fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after drop_caches fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:112: TPASS: FAN_MARK_ADD failed with EEXIST as expected when trying to downgrade to evictable mark fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after empty mask fanotify23.c:156: TPASS: Got no events as expected fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after drop_caches fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:193: TPASS: got event: mask=4 fanotify23.c:112: TPASS: FAN_MARK_ADD failed with EEXIST as expected when trying to downgrade to evictable mark fanotify23.c:75: TPASS: FAN_MARK_REMOVE failed with ENOENT as expected after empty mask fanotify23.c:156: TPASS: Got no events as expected fanotify23.c:81: TFAIL: FAN_MARK_REMOVE did not fail with ENOENT as expected after drop_caches: SUCCESS (0) fanotify23.c:175: TBROK: read(3,0x5598cbfafc54,24524) failed, returned -1: EAGAIN/EWOULDBLOCK (11) Summary: passed 27 failed 1 broken 1 skipped 0 warnings 0 dmesg: [ 371.377308][T29983] loop: module loaded [ 371.380510][T29982] loop0: detected capacity change from 0 to 614400 [ 371.441931][ C1] clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc' as unstable because the skew is too large: [ 371.443816][ C1] clocksource: 'kvm-clock' wd_nsec: 515886747 wd_now: 5749149153 wd_last: 572a54c2b8 mask: ffffffffffffffff [ 371.445730][ C1] clocksource: 'tsc' cs_nsec: 30542623402 cs_now: cff3ae7e60 cs_last: c057e04270 mask: ffffffffffffffff [ 371.447768][ C1] clocksource: Clocksource 'tsc' skewed 30026736655 ns (30026 ms) over watchdog 'kvm-clock' interval of 515886747 ns (515 ms) [ 371.449822][ C1] clocksource: 'kvm-clock' (not 'tsc') is current clocksource. [ 371.451068][ C1] tsc: Marking TSC unstable due to clocksource watchdog [ 371.499239][ C1] operation not supported error, dev loop0, sector 614272 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.501256][ C0] operation not supported error, dev loop0, sector 524 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.503893][ C1] operation not supported error, dev loop0, sector 16908 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.506135][ C0] operation not supported error, dev loop0, sector 32774 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.508716][ C1] operation not supported error, dev loop0, sector 49676 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.511513][ C0] operation not supported error, dev loop0, sector 65542 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.514038][ C0] operation not supported error, dev loop0, sector 82444 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.516522][ C1] operation not supported error, dev loop0, sector 98310 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.519263][ C0] operation not supported error, dev loop0, sector 115212 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.521950][ C1] operation not supported error, dev loop0, sector 131078 op 0x9:(WRITE_ZEROES) flags 0x8000800 phys_seg 0 prio class 2 [ 371.545611][T29982] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem [ 371.548719][T29982] EXT4-fs (loop0): mounted filesystem f9e6e295-a78d-4551-aff2-ce1663458053 without journal. Quota mode: none. [ 371.787570][T30005] fanotify23 (30005): drop_caches: 3 [ 371.804729][T30005] EXT4-fs (loop0): unmounting filesystem f9e6e295-a78d-4551-aff2-ce1663458053. [ 371.810253][T30005] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem [ 371.812114][T30005] EXT4-fs (loop0): mounted filesystem f9e6e295-a78d-4551-aff2-ce1663458053 without journal. Quota mode: none. [ 371.820273][T30005] fanotify23 (30005): drop_caches: 3 [ 371.828227][T30005] EXT4-fs (loop0): unmounting filesystem f9e6e295-a78d-4551-aff2-ce1663458053. [ 371.830160][T30005] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem [ 371.831957][T30005] EXT4-fs (loop0): mounted filesystem f9e6e295-a78d-4551-aff2-ce1663458053 without journal. Quota mode: none. [ 371.841016][T30005] fanotify23 (30005): drop_caches: 3 [ 371.862288][T30005] EXT4-fs (loop0): unmounting filesystem f9e6e295-a78d-4551-aff2-ce1663458053. [ 371.864165][T30005] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem [ 371.866232][T30005] EXT4-fs (loop0): mounted filesystem f9e6e295-a78d-4551-aff2-ce1663458053 without journal. Quota mode: none. [ 371.872592][T30005] fanotify23 (30005): drop_caches: 3 [ 371.890441][T30005] EXT4-fs (loop0): unmounting filesystem f9e6e295-a78d-4551-aff2-ce1663458053. [ 371.892294][T30005] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem [ 371.894159][T30005] EXT4-fs (loop0): mounted filesystem f9e6e295-a78d-4551-aff2-ce1663458053 without journal. Quota mode: none. [ 371.900270][T30005] fanotify23 (30005): drop_caches: 3 [ 371.919626][T29982] EXT4-fs (loop0): unmounting filesystem f9e6e295-a78d-4551-aff2-ce1663458053. When running on Debian 6.3.0-1-amd64 test does not fail and dmesg does not contain clocksource and tsc, therefore I suspect it's something our kernel specific (our configuration specific? We don't have any fanotify related patch, only something old patches.suse/vfs-add-super_operations-get_inode_dev, which is IMHO unrelated). I can report it to linux-fsdevel ML if it's a general problem. [1] https://github.com/linux-test-project/ltp/blob/353f0e4203139f3fc02fa2beb67c… [2] https://openqa.opensuse.org/tests/overview?build=fanotify23-10x -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1212824] New: [Build 20230627] apptainer: Write failed because no space left on device
by bugzilla_noreply＠suse.com 10 Aug '23

10 Aug '23

https://bugzilla.suse.com/show_bug.cgi?id=1212824 Bug ID: 1212824 Summary: [Build 20230627] apptainer: Write failed because no space left on device Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/3390518/modules/appt ainer/steps/42 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation Since today, the hpc_apptainer test is failing with 'no space on device' df shows sufficient space left: Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 728M 0 728M 0% /dev/shm tmpfs 292M 4.9M 287M 2% /run /dev/vda2 28G 2.3G 26G 9% / tmpfs 728M 24K 728M 1% /tmp /dev/vda2 28G 2.3G 26G 9% /.snapshots /dev/vda2 28G 2.3G 26G 9% /home /dev/vda2 28G 2.3G 26G 9% /var /dev/vda2 28G 2.3G 26G 9% /boot/grub2/i386-pc /dev/vda2 28G 2.3G 26G 9% /boot/grub2/x86_64-efi /dev/vda2 28G 2.3G 26G 9% /usr/local /dev/vda2 28G 2.3G 26G 9% /opt /dev/vda2 28G 2.3G 26G 9% /root /dev/vda2 28G 2.3G 26G 9% /srv tmpfs 146M 0 146M 0% /run/user/0 openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-containers_hpc_apptainer@64bit fails in [apptainer](https://openqa.opensuse.org/tests/3390518/modules/apptainer/step… ## Test suite description Maintainer: dheidler. Extra tests about CLI software in container module ## Reproducible Fails since (at least) Build [20230627](https://openqa.opensuse.org/tests/3389026) ## Expected result Last good: [20230626](https://openqa.opensuse.org/tests/3383456) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1212891] New: Win11 installation fails with process stopping in firware
by bugzilla_noreply＠suse.com 31 Jul '23

31 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212891 Bug ID: 1212891 Summary: Win11 installation fails with process stopping in firware Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: KVM Assignee: kvm-bugs(a)suse.de Reporter: stakanov(a)disroot.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- when trying to install a recent(!) image of Win11 in KVM in a machine with either paththrough of TPM or virtualized TPM the process stalls in "firmware Tiano Core". There is no error message, the iso simply stalls when loading the Tiano Core firmware. I tried also to download another image, I checked the checksum. But still, even if selecting correctly the iso, no luck. Operating System: openSUSE Tumbleweed 20230628 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Kernel Version: 6.3.9-1-default (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 62.6 GiB of RAM Graphics Processor: AMD Radeon Pro W5500 Product Name: X570 Phantom Gaming 4 Image hit by this is: Win11_22H2_Italian_x64v2.iso -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1212866] New: AUDIT-1: gromox: gromox-snapshot running as root
by bugzilla_noreply＠suse.com 24 Jul '23

24 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212866 Bug ID: 1212866 Summary: AUDIT-1: gromox: gromox-snapshot running as root Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: wolfgang.frisch(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- openSUSE:Factory/gromox was recently updated with a change to one of its systemd services: > -RPM: gromox-2.9-1.2.x86_64.rpm on x86_64 > +RPM: gromox-2.10-1.1.x86_64.rpm on x86_64 > Package: gromox > Service path: /usr/lib/systemd/system/gromox-snapshot.service > -Runs as: gromox:gromox > +Runs as: root:root > Exec lines: > ExecStart=/usr/libexec/gromox/gromox-snapshot The last version of gromox-snapshot did not require root, so we should consider if this is necessary at all. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1212897] New: Produce separate Aeon installation media
by bugzilla_noreply＠suse.com 24 Jul '23

24 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212897 Bug ID: 1212897 Summary: Produce separate Aeon installation media Classification: openSUSE Product: openSUSE Aeon Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Base Assignee: rbrown(a)suse.com Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Aeon requires install media separate from MicroOS -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1212811] New: MokManager wants to remove needed cert
by bugzilla_noreply＠suse.com 10 Jul '23

10 Jul '23

https://bugzilla.suse.com/show_bug.cgi?id=1212811 Bug ID: 1212811 Summary: MokManager wants to remove needed cert Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: nwr10cst-oslnx(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Build Identifier: I'm currently using a kernel from Kernel:/stable:/Backport/standard/ (as explained in bug 1212808 ). Yesterday, I decided to update that kernel (from 6.3.9-lp154.2.1.g0df701d to 6.4.0-lp154.2.1.gd68cda5). To do this: I enabled the repo I used Yast software management I told it to install the newer kernel and remove the older one I then disabled the repo once again On reboot, I got a MokManager blue screen wanting to remove the cert that had been added for the older kernel. This seems a mistake, since it is still needed for the newer kernel. As best I can tell, Yast first removed the older kernel and that generated a request to remove the cert. It then installed the newer kernel, but because the cert was already loaded it did not generate a request to add the cert. (When I next update this kernel, I'll make sure to install the new kernel first, and then remove the old kernel afterwards to avoid this issue). Yes, I could have left it to the purge-kernels service to remove the old. But that would have instead removed the standard Leap 15.5 kernel, and I wanted to avoid that. Reproducible: Didn't try -- You are receiving this mail because: You are on the CC list for the bug.

1 1

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs June 2023