September 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1203223] New: GDM does not start at boot
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203223 Bug ID: 1203223 Summary: GDM does not start at boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: sionescu(a)cddr.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 861359 --> http://bugzilla.opensuse.org/attachment.cgi?id=861359&action=edit Xorg.0.log At boot, GDM fails to start on VT0. If, after the boot is completed, and the login prompt appears, I switch to VT1 (by pressing Alt-F2), GDM starts. I'm using the proprietary Nvidia driver (nvidia-glG06-515.65.01-lp154.15.1). /var/log/Xorg.0.log contains a crash (I've attached the entire log): [ 26.526] (II) Module fb: vendor="X.Org Foundation" [ 26.526] compiled for 1.20.3, module version = 1.0.0 [ 26.526] ABI class: X.Org ANSI C Emulation, version 0.4 [ 26.527] (EE) [ 26.527] (EE) Backtrace: [ 26.527] (EE) 0: /usr/bin/X (xorg_backtrace+0x65) [0x561eb75b2525] [ 26.527] (EE) 1: /usr/bin/X (0x561eb7400000+0x1b61f9) [0x561eb75b61f9] [ 26.527] (EE) 2: /lib64/libpthread.so.0 (0x7f14b8fee000+0x168c0) [0x7f14b90048c0] [ 26.527] (EE) 3: /lib64/libc.so.6 (gsignal+0x10d) [0x7f14b8c43cdb] [ 26.527] (EE) 4: /lib64/libc.so.6 (abort+0x177) [0x7f14b8c45375] [ 26.527] (EE) 5: /lib64/libc.so.6 (0x7f14b8bf9000+0x42cda) [0x7f14b8c3bcda] [ 26.527] (EE) 6: /lib64/libc.so.6 (0x7f14b8bf9000+0x42d62) [0x7f14b8c3bd62] [ 26.527] (EE) 7: /usr/bin/X (dixRegisterPrivateKey+0x23f) [0x561eb747b47f] [ 26.527] (EE) 8: /usr/lib64/xorg/modules/libglamoregl.so (glamor_init+0xca) [0x7f132ea0c57a] [ 26.527] (EE) 9: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0x7f132ec36000+0x11e1d) [0x7f132ec47e1d] [ 26.527] (EE) 10: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0x7f132ec36000+0x9bf4) [0x7f132ec3fbf4] [ 26.527] (EE) 11: /usr/bin/X (AddGPUScreen+0xf0) [0x561eb745d190] [ 26.527] (EE) 12: /usr/bin/X (0x561eb7400000+0xb761c) [0x561eb74b761c] [ 26.527] (EE) 13: /usr/bin/X (0x561eb7400000+0xbd041) [0x561eb74bd041] [ 26.527] (EE) 14: /usr/bin/X (0x561eb7400000+0xb931f) [0x561eb74b931f] [ 26.527] (EE) 15: /usr/bin/X (0x561eb7400000+0xb9ecb) [0x561eb74b9ecb] [ 26.527] (EE) 16: /usr/bin/X (config_init+0x9) [0x561eb74b8919] [ 26.527] (EE) 17: /usr/bin/X (InitInput+0xc7) [0x561eb749c4a7] [ 26.527] (EE) 18: /usr/bin/X (0x561eb7400000+0x60d35) [0x561eb7460d35] [ 26.527] (EE) 19: /lib64/libc.so.6 (__libc_start_main+0xef) [0x7f14b8c2e2bd] [ 26.528] (EE) 20: /usr/bin/X (_start+0x2a) [0x561eb744aa1a] [ 26.528] (EE) [ 26.528] (EE) Fatal server error: [ 26.528] (EE) Caught signal 6 (Aborted). Server aborting -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203027] No way of setting mount points for btrfs subvolumes in YaST
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1203027 https://bugzilla.suse.com/show_bug.cgi?id=1203027#c9 --- Comment #9 from Richard Brown <rbrown(a)suse.com> --- (In reply to Ancor Gonzalez Sosa from comment #8) > BEWARE: philosophical conversation/digression ahead (not really useful to > get the main issue addressed). > > In the TPM2 example, is not that YaST decided to use a password instead of > TPM2 for LUKS2 unlocking. It's simply that using a passphrase is the only > way YaST knows. So the user cannot "correct" the proposal to use a different > unlocking mechanism, even if that is something that can perfectly be done > manually. We are not talking about the automatic proposal choosing the wrong > option, we are talking about YaST limitations and lack of features. > > In the same way, subvolumes in YaST have been historically limited to just > be mounted below its file-system according to the path of the subvolume (so > they are treated as subdirectories on steroids). It has been like that since > Btrfs was introduced in the distribution. YaST has never offered the > possibility to adjust the mount point or the mount options of a subvolume in > a completely independent and arbitrary way. Cannot be done with the Expert > Partitioner, cannot be done with AutoYaST, cannot be configured in the > control file and, of course, the installer cannot propose it automatically. Except..YaST doesn't mount the subvolumes according to the path of the subvolume The path of the default subvolumes is /@/$foo YaST isn't mounting them as /@/$foo for all the default subvolumes, but doing some magic to mount them all as /$foo This magic _CAN_ be configured by the control file by the following variable <btrfs_default_subvolume> (usually @) subvolumes $foo are defined by the <subvolumes> and <subvolume> parameters YaST then does its magic munging <btrfs_default_subvolume> and <subvoulmes> together to make its automatic proposal...and if users don't like it..users be damned.. This is why I consider this bug a bug and not a feature request. > > > The fact that YaST is auto-calculating mount points for subvolumes and not > > giving users a chance to correct any mistakes and/or set mount points for > > any additional subvolumes sure still feels like a bug to me that runs > > counter to how we typically do everything else in YaST... > > I disagree with reasoning done to get to the idea that the current subvolume > handling goes counter to how we do things in YaST (already explained). > Having said that, I don't think it makes a big difference calling it a bug > or a (lack of) feature. That doesn't change the fact that allowing totally > arbitrary mount points (and mount options) per subvolume implies changing > the whole historical approach of YaST to subvolumes. That means deep changes > would be needed in YaST. Changes in the user interface, changes in the > AutoYaST schema and, of course, internal changes. > > We really want to improve that part, but sadly we have not found time in the > last couple of years because the people who sets the priorities always had > something more pressuring. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203103] Kernel oops on BPF trace after AMD retbleed patch
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1203103 https://bugzilla.suse.com/show_bug.cgi?id=1203103#c4 --- Comment #4 from pk-pavlk <pk-dev-bzilla.rcd10(a)simplelogin.com> --- Created attachment 861356 --> https://bugzilla.suse.com/attachment.cgi?id=861356&action=edit full dmesg with latest kernel from Kernel:SLE15-SP4 repo I have already removed that kernel, so I retested with latest build (5.14.21-150400.221.g2e0f852-default). Still behaves the same, full dmesg is attached. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1182345] New: go1.16 release tracking
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1182345 Bug ID: 1182345 Summary: go1.16 release tracking Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: jkowalczyk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- go1.16 (released 2021-02-16) is a major release of Go. Minor releases of go1.16.x will be provided through February 2022. This issue tracks go1.16.x releases packaged and submitted initially to openSUSE:Factory and can be referenced in submissions to additional repositories. Go Release Cycle https://github.com/golang/go/wiki/Go-Release-Cycle Go Release history https://golang.org/doc/devel/release.html -- You are receiving this mail because: You are on the CC list for the bug.

1 39

[Bug 1190649] go1.17 release tracking
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1190649 https://bugzilla.suse.com/show_bug.cgi?id=1190649#c51 --- Comment #51 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2022:3155-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1190649 CVE References: JIRA References: Sources used: openSUSE Leap 15.4 (src): go1.17-1.17.13-150000.1.45.1 openSUSE Leap 15.3 (src): go1.17-1.17.13-150000.1.45.1 SUSE Linux Enterprise Module for Development Tools 15-SP4 (src): go1.17-1.17.13-150000.1.45.1 SUSE Linux Enterprise Module for Development Tools 15-SP3 (src): go1.17-1.17.13-150000.1.45.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1193742] go1.18 release tracking
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1193742 https://bugzilla.suse.com/show_bug.cgi?id=1193742#c30 --- Comment #30 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2022:3157-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1193742 CVE References: JIRA References: Sources used: openSUSE Leap 15.4 (src): go1.18-1.18.5-150000.1.28.1 openSUSE Leap 15.3 (src): go1.18-1.18.5-150000.1.28.1 SUSE Linux Enterprise Module for Development Tools 15-SP4 (src): go1.18-1.18.5-150000.1.28.1 SUSE Linux Enterprise Module for Development Tools 15-SP3 (src): go1.18-1.18.5-150000.1.28.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 997317] New: grub2-branding lacks posttrans
by bugzilla_noreply＠novell.com 07 Sep '22

07 Sep '22

http://bugzilla.suse.com/show_bug.cgi?id=997317 Bug ID: 997317 Summary: grub2-branding lacks posttrans Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- grub2-branding creates a grub2.cfg in its %post. this is a very expensive operation, in combination with os-prober. there is nothing in that pkg which requires immediate action. cumulate the required steps and do it once in a single %posttrans. -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1203088] New: Patch should not conflict with packages from different vendor (on example of patch:openSUSE-SLE-15.4-2022-2969)
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203088 Bug ID: 1203088 Summary: Patch should not conflict with packages from different vendor (on example of patch:openSUSE-SLE-15.4-2022-2969) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: arvidjaar(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 861285 --> http://bugzilla.opensuse.org/attachment.cgi?id=861285&action=edit zypper patch with conflict with Packman part 1 Consider bor@10:~> zypper lp Loading repository data... Reading installed packages... Repository | Name | Category | Severity | Interactive | Status | Summary -------------------------------------------------------------+-----------------------------+----------+----------+-------------+----------+------------------------------------- Update repository with updates from SUSE Linux Enterprise 15 | openSUSE-SLE-15.4-2022-2969 | optional | moderate | --- | optional | Optional update for SUSE Package Hub Found 1 applicable patch: 1 patch optional (use '--with-optional' to include optional patches) 0 patches needed (0 security patches) bor@10:~> sudo zypper patch --with-optional Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed patch:openSUSE-SLE-15.4-2022-2969-1.noarch conflicts with 'libswscale5_9.x86_64 < 4.4-150400.3.2.1' provided by the installed libswscale5_9-4.4-pm154.2.6.x86_64 Solution 1: Following actions will be done: install libswscale5_9-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libswscale5_9-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libswresample3_9-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libswresample3_9-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libpostproc55_9-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libpostproc55_9-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libavutil56_70-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libavutil56_70-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libavresample4_0-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libavresample4_0-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libavformat58_76-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libavformat58_76-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libavfilter7_110-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libavfilter7_110-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de install libavcodec58_134-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/> replacing libavcodec58_134-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de Solution 2: do not install patch:openSUSE-SLE-15.4-2022-2969-1.noarch Choose from above solutions by number or cancel [1/2/c/d/?] (c): But that is wrong. These packages are from another vendor/repository so patch for (open)SUSE packages is not applicable to them at all. Moreover, it I update the outdated package(s) from SUSE, the patch is no more considered applicable, even though the same "downrev" ffmpeg libraries are still present. This is certainly inconsistent. bor@10:~> sudo zypper up Loading repository data... Reading installed packages... The following 14 package updates will NOT be installed: libavcodec57 libavcodec58_134 libavfilter7_110 libavformat57 libavformat58_76 libavresample4_0 libavutil55 libavutil56_70 libfdk-aac2 libpostproc55_9 libswresample2 libswresample3_9 libswscale4 libswscale5_9 The following package is going to be upgraded: gucharmap 1 package to upgrade. Overall download size: 123.3 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y): Retrieving package gucharmap-13.0.0-150400.4.2.3.x86_64 (1/1), 123.3 KiB (278.1 KiB unpacked) Retrieving: gucharmap-13.0.0-150400.4.2.3.x86_64.rpm .....................[done] Checking for file conflicts: .............................................[done] (1/1) Installing: gucharmap-13.0.0-150400.4.2.3.x86_64 ...................[done] bor@10:~> zypper lp Loading repository data... Reading installed packages... No updates found. bor@10:~> I attach two debug solver cases, one for "zypper patch" with outdated package gucharmap and one with "zypper patch" where the only "downrev" packages are from Packman. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1187656] New: mdadm: mdcheck_start.state is in "activating" for up to 6 hrs
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1187656 Bug ID: 1187656 Summary: mdadm: mdcheck_start.state is in "activating" for up to 6 hrs Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: daniel.molkentin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The /usr/lib/systemd/system/mdcheck_start.service file states the following: [Service] Type=oneshot Environment="MDADM_CHECK_DURATION=6 hours" "oneshot" implies that the service will remain in "activating" state for the entire duration (long, up to the stated 6 hours. It would be better to use Type=simple, which does not keep the unit in "activating" mode. This is an important difference in semantics, because monitoring tools (e.g. prometheus) tend to alert if a unit is stuck in "activating" for more than (typically) 5 minutes (which usually makes sense, but not here). The only side effect that I could find is that systemd will not wait for follow-up units to start, but since this is a timer-triggered unit, I would not expect anyone else to depend on this service. Verified by adding an override file. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1203103] Kernel oops on BPF trace after AMD retbleed patch
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1203103 https://bugzilla.suse.com/show_bug.cgi?id=1203103#c3 --- Comment #3 from Borislav Petkov <bpetkov(a)suse.com> --- can you upload full dmesg from that kernel? Thx. -- You are receiving this mail because: You are on the CC list for the bug.

1 0