- openSUSE Kernel Bugs

[Bug 1222674] BTRFS Snapshots failing since kernel 6.8.4rc1, still working on 6.8.2
by bugzilla_noreply＠suse.com 12 Apr '24

12 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222674 https://bugzilla.suse.com/show_bug.cgi?id=1222674#c5 --- Comment #5 from Arvin Schnell <aschnell(a)suse.com> --- The logs show that btrfs_util_create_snapshot_fd2() fails with errno = 2 (No such file or directory). That is very strange since the function gets two file descriptors and one path. The path is constant ("snapshot") and is created - so should never exist beforehand. If one of the file descriptors is wrong I would expect a different errno. Maybe the errno of 2 is a leftover of a previous ioctl. Can someone who can reproduce the problem compile snapper and place an 'errno = 0;' before the btrfs_util_create_snapshot_fd2 in BtrfsUtils.cc? Also, are there any error messages in dmesg or journalctl? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1222674] BTRFS Snapshots failing since kernel 6.8.4rc1, still working on 6.8.2
by bugzilla_noreply＠suse.com 12 Apr '24

12 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222674 https://bugzilla.suse.com/show_bug.cgi?id=1222674#c4 --- Comment #4 from pallas wept <pallaswept(a)proton.me> --- Sorry to hear it, Ingo. FWIW, I don't get the snapshot check errors. This is from one of my failing hourly snapshots: > 2024-04-12 22:00:00 MIL libsnapper(28132) snapperd.cc(main):283 - Requesting DBus name > 2024-04-12 22:00:00 MIL libsnapper(28132) snapperd.cc(main):298 - Loading snapper configs > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(getConfigs):355 - Snapper get-configs > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(getConfigs):356 - libsnapper version 0.10.7 > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(reload):922 - loading file /etc/sysconfig/snapper > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SNAPPER_CONFIGS value:root home > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(reload):922 - loading file /etc/snapper/configs/root > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SUBVOLUME value:/ > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(reload):922 - loading file /etc/snapper/configs/home > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SUBVOLUME value:/home > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:ALLOW_USERS value: > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:ALLOW_GROUPS value: > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:ALLOW_USERS value: > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:ALLOW_GROUPS value: > 2024-04-12 22:00:00 MIL libsnapper(28132) snapperd.cc(main):311 - Listening for method calls and signals > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):97 - Snapper constructor > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):98 - snapper version 0.10.7 > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):99 - libsnapper version 7.4.0 > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):100 - config_name:home root_prefix:/ disable_filters:false > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(reload):922 - loading file /etc/snapper/configs/home > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SUBVOLUME value:/home > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:FSTYPE value:btrfs > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:QGROUP value: > 2024-04-12 22:00:00 MIL libsnapper(28132) Selinux.cc(_is_selinux_enabled):141 - SELinux support disabled > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SYNC_ACL value:no > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):130 - subvolume:/home filesystem:btrfs > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(loadIgnorePatterns):204 - number of ignore patterns:8 > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapshot.cc(read):344 - found 25 snapshots > 2024-04-12 22:00:00 WAR libsnapper(28132) FileUtils.cc(SDir):88 - THROW: open failed path:/home/.snapshots/8185 errno:2 (No such file or directory) > 2024-04-12 22:00:00 WAR libsnapper(28132) Btrfs.cc(checkSnapshot):490 - CAUGHT: open failed path:/home/.snapshots/8185 errno:2 (No such file or directory) > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):97 - Snapper constructor > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):98 - snapper version 0.10.7 > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):99 - libsnapper version 7.4.0 > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):100 - config_name:root root_prefix:/ disable_filters:false > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(reload):922 - loading file /etc/snapper/configs/root > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SUBVOLUME value:/ > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:FSTYPE value:btrfs > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:QGROUP value:1/0 > 2024-04-12 22:00:00 MIL libsnapper(28132) AsciiFile.cc(get_value):1078 - key:SYNC_ACL value:no > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(Snapper):130 - subvolume:/ filesystem:btrfs > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapper.cc(loadIgnorePatterns):204 - number of ignore patterns:8 > 2024-04-12 22:00:00 MIL libsnapper(28132) Snapshot.cc(read):344 - found 90 snapshots > 2024-04-12 22:00:00 WAR libsnapper(28132) FileUtils.cc(SDir):88 - THROW: open failed path://.snapshots/9891 errno:2 (No such file or directory) > 2024-04-12 22:00:00 WAR libsnapper(28132) Btrfs.cc(checkSnapshot):490 - CAUGHT: open failed path://.snapshots/9891 errno:2 (No such file or directory) > 2024-04-12 22:00:00 ERR libsnapper(28132) Btrfs.cc(createSnapshot):328 - create snapshot failed, btrfs_util_create_snapshot_fd2() failed, errno:2 (No such file or directory) > 2024-04-12 22:00:00 WAR libsnapper(28132) Btrfs.cc(createSnapshot):329 - THROW: create snapshot failed > 2024-04-12 22:00:00 WAR libsnapper(28132) Snapshot.cc(createHelper):780 - CAUGHT: create snapshot failed > 2024-04-12 22:00:00 WAR libsnapper(28132) Snapshot.cc(createHelper):785 - RETHROW: create snapshot failed > 2024-04-12 22:00:00 WAR libsnapper(28132) Client.cc(dispatch):1983 - CAUGHT: create snapshot failed > 2024-04-12 22:00:00 WAR libsnapper(28130) DBusConnection.cc(send_with_reply_and_block):104 - THROW: dbus error exception > 2024-04-12 22:00:30 MIL libsnapper(28132) Snapper.cc(~Snapper):142 - Snapper destructor > 2024-04-12 22:00:30 MIL libsnapper(28132) Snapper.cc(~Snapper):142 - Snapper destructor > 2024-04-12 22:01:00 MIL libsnapper(28132) snapperd.cc(main):315 - Exiting -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1219284] increased ram usage after upgrading from 6.6.x to 6.7.x
by bugzilla_noreply＠suse.com 11 Apr '24

11 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1219284 https://bugzilla.suse.com/show_bug.cgi?id=1219284#c22 Andrea Manzini <andrea.manzini(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #22 from Andrea Manzini <andrea.manzini(a)suse.com> --- closing this as fixed -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1218184] New: Eliminate the need for 'OBS source links': convert to _multibuild
by bugzilla_noreply＠suse.com 10 Apr '24

10 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1218184 Bug ID: 1218184 Summary: Eliminate the need for 'OBS source links': convert to _multibuild Classification: SUSE ALP - SUSE Adaptable Linux Platform Product: Dolomite Version: Milestone 5 Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)suse.de Reporter: fcrozat(a)suse.com CC: dimstar(a)opensuse.org, dleuenberger(a)suse.com, fcrozat(a)suse.com, jslaby(a)suse.com, kernel-bugs(a)opensuse.org, mls(a)suse.com, msuchanek(a)suse.com, qa-bugs(a)suse.de, tiwai(a)suse.com Depends on: 1211226 Target Milestone: --- Group: SUSE Enterprise Partner Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1211226 +++ In order to prepare for 'git based source management', we need to fix up a few technical issues. One such issue is 'source links' not being supported in git (i.e in OBS we have openSUSE:Factory/kernel-source as the main package plus a bunch of 'linked packages', each with the name of the additional spec files) The solution is, technically seem, rather simple: using _multibuild multibuild support on OBS is known in two variants, one using a single spec file and conditionals inside the spec file based on @BUILD_FLAVOR@ (probably the more known way) but OBS also supports 'just' listing the additional spec files as 'flavors' the _multibuild to be added to the kernel-source (main package) can be generated like this:  #!/bin/sh echo "<multibuild>" > _multibuild for pkg in *.spec; do test "{$pkg}" == "kernel-source.spec" && continue echo " <package>${pkg/.spec/}</package>" >> _multibuild; done echo "</multibuild>" >> _multibuild  the spec files do not need to be changed in anyway with this method -- You are receiving this mail because: You are on the CC list for the bug.

1 59

[Bug 1211226] Eliminate the need for 'OBS source links': convert to _multibuild
by bugzilla_noreply＠suse.com 10 Apr '24

10 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1211226 Bug 1211226 depends on bug 1218998, which changed state. Bug 1218998 Summary: cannot abort build/restart build/wipe binaries for multibuild packages https://bugzilla.suse.com/show_bug.cgi?id=1218998 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1221504] bluetooth errors on every kernel starting
by bugzilla_noreply＠suse.com 10 Apr '24

10 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1221504 https://bugzilla.suse.com/show_bug.cgi?id=1221504#c19 --- Comment #19 from Andreas <opendreas(a)gmail.com> --- (In reply to Takashi Iwai from comment #15) > OK, then it should be reported to the upstream devs. > Care to do that from your side? At best, write to linux-bluetooth ML. Feel > free to put me (tiwai(a)suse.de) to Cc. > Alternatively, you can report to bugzilla.kernel.org, but it gets little > attention in general. (In reply to Takashi Iwai from comment #15) > OK, then it should be reported to the upstream devs. > Care to do that from your side? At best, write to linux-bluetooth ML. Feel > free to put me (tiwai(a)suse.de) to Cc. > Alternatively, you can report to bugzilla.kernel.org, but it gets little > attention in general. I created a new issue, but I don't see an option to add you to the CC list on github. https://github.com/bluez/bluez/issues/809 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193599] intel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
by bugzilla_noreply＠suse.com 09 Apr '24

09 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1193599 https://bugzilla.suse.com/show_bug.cgi?id=1193599#c46 --- Comment #46 from Andreas <opendreas(a)gmail.com> --- (In reply to Paolo De Pasquale from comment #45) > (In reply to Andreas from comment #44) > > > No. One user attributes these errors to freezes in Wine and WeChat. > > I can confirm wine freezes on my Thinkpad ThinkPad P15 Gen 1 running TW > 20240402 It would probably be nice to write about this on GitLab and attach the log. https://gitlab.freedesktop.org/drm/intel/-/issues/4458#note_2336439 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193599] intel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
by bugzilla_noreply＠suse.com 09 Apr '24

09 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1193599 https://bugzilla.suse.com/show_bug.cgi?id=1193599#c45 --- Comment #45 from Paolo De Pasquale <paolo.depasquale(a)suse.com> --- (In reply to Andreas from comment #44) > No. One user attributes these errors to freezes in Wine and WeChat. I can confirm wine freezes on my Thinkpad ThinkPad P15 Gen 1 running TW 20240402 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193599] intel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
by bugzilla_noreply＠suse.com 09 Apr '24

09 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1193599 https://bugzilla.suse.com/show_bug.cgi?id=1193599#c44 --- Comment #44 from Andreas <opendreas(a)gmail.com> --- Created attachment 874166 --> https://bugzilla.suse.com/attachment.cgi?id=874166&action=edit journald-6.4.0-150600.1-patched (In reply to Takashi Iwai from comment #43) > (In reply to Andreas from comment #40) > > The following message contains patches from the Intel developer. > > https://patchwork.freedesktop.org/series/125157/ > > The patches aren't included in the upstream (yet?). No. One user attributes these errors to freezes in Wine and WeChat. I don't use these programs so I can't confirm this. The Intel developer says they can't do anything because... no access to proprietary nvidia module. In theory, these errors occur when nothing is connected to the HDMI port. > I'm building a test kernel for SLE15-SP6 in OBS home:tiwai:bsc1193599-sp6 > repo. > The package will appear later at > http://download.opensuse.org/repositories/home:/tiwai:/bsc1193599-sp6/pool/ > > Please give it a try later. The patch works, the errors have disappeared. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1222345] Laptop wakes from suspend once the user closes the lid
by bugzilla_noreply＠suse.com 06 Apr '24

06 Apr '24

https://bugzilla.suse.com/show_bug.cgi?id=1222345 https://bugzilla.suse.com/show_bug.cgi?id=1222345#c8 --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- Then some spurious interrupt must be waking up the machine. Please check the following: - Enable/disable LID ACPI: To check the status: % cat /proc/acpi/wakeup To toggle the status: % echo LID > /proc/acpi/wakeup If this doesn't influence, it's something else than ACPI wakeup. Then, you can try the direct suspend by echo mem > /sys/power/state Does it behave differently? -- You are receiving this mail because: You are the assignee for the bug.

1 0