October 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1189841] Secure Boot certificate no longer queued for import into MOK
by bugzilla_noreply＠suse.com 06 Oct '21

06 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1189841 http://bugzilla.opensuse.org/show_bug.cgi?id=1189841#c67 --- Comment #67 from OBSbugzilla Bot <bwiedemann+obsbugzillabot(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (1189841) was mentioned in https://build.opensuse.org/request/show/923361 15.2 / kernel-source -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1187167] kernel-default varies across builds
by bugzilla_noreply＠suse.com 06 Oct '21

06 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187167 http://bugzilla.opensuse.org/show_bug.cgi?id=1187167#c55 --- Comment #55 from OBSbugzilla Bot <bwiedemann+obsbugzillabot(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (1187167) was mentioned in https://build.opensuse.org/request/show/923361 15.2 / kernel-source -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190631] TLP unnecessarily pulls in bbswitch
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

https://bugzilla.suse.com/show_bug.cgi?id=1190631 https://bugzilla.suse.com/show_bug.cgi?id=1190631#c3 --- Comment #3 from Stanislav Brabec <sbrabec(a)suse.com> --- Well, my ThinkPad Carbon X1 4th gen works with both bbswitch and acpi_call. (Just bbswitch causes a warning somewhere in the tlp.) But acpi_call is not part of Tumbleweed, that is why I added bbswitch. And especially because acpi_call looks as an orphan piece of code. If there are devices not supported by bbswitch, my solution is not correct from the packaging aspect of view. So I can imagine three ways to continue: 1. Easy way. Needs user interaction. tlp.spec: Recommends: call_ACPI_method bbswitch.spec: Provides: call_ACPI_method acpi_call.spec: Provides: call_ACPI_method 2. Hardware specific way. Use hardware ZYPP symbols instead of Recommends. It should work out of the box, but it will require a collection of board ids: bbswitch.spec: acpi_call.spec: Supplements: packageand(tlp:modalias(pci:{a hardware ZYPP symbol provided by supported device})) tlp.spec: nothing special Then these packages recommendations will depend on the hardware. It needs some work to identify all systems that have battery control support, and then pick an unique (probably PCI) ID. 3. Correct way. Identify a reason, why some devices are not supported in bbswitch, and improve the bbswitch module. It would need to involve a kernel developer. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1191247] audio goes to mono after waking up from sleep
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1191247 http://bugzilla.opensuse.org/show_bug.cgi?id=1191247#c12 --- Comment #12 from Andrea P <pandre.x(a)gmail.com> --- (In reply to Takashi Iwai from comment #11) > Oh, and now I see you have Audient device in the card 0, judging from > alsa-info.sh output. In that case, test is like > aplay -Dplughw:0 somefile.wav > > The card index varies dynamically, so please check the output of "cat > /proc/asound/cards" beforehand. here I am! so, long story short: it doesn't matter what I do, after suspend the audio goes mono. In any single attempt I've checked if my sound card index was correct and it was. I tried to login as root and restart the usb module and as a matter of fact, it works straight away. so no "device or resource busy" anymore, but still, once I restart it the audio is still in mono. No idea if pulseaudio/pipewire still works even on Linux console, sorry. What else can I do for you? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190856] New: tensorflow2 2.6.0 is missing some requirements
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1190856 Bug ID: 1190856 Summary: tensorflow2 2.6.0 is missing some requirements Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: code(a)bnavigator.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Some of the updated requirements of tensorflow 2.6.0 are missing. keras has been outsourced to a separate repo again. It is still supposed to be imported through from tensorflow import keras, which succeeeds. But if it is not installed as a separate module, any access to an attribute results in a ModuleNotFound error, due to an error in the LazyLoader. This is also the reason for the build failure in python-Keras-Preprocessing. Similar for tensorflow_estimator. Additionally, the tensorboard library is also outsourced and expected by keras. Executing tensorflow's tensorboard entry_point results in an error. Compare https://github.com/tensorflow/tensorflow/blob/v2.6.0/tensorflow/tools/pip_p… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1191246] Package "virt-install" seem to install a lot of GUI packages
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

https://bugzilla.suse.com/show_bug.cgi?id=1191246 https://bugzilla.suse.com/show_bug.cgi?id=1191246#c4 --- Comment #4 from Brian Wengel <m40636067(a)gmail.com> --- Hi Charles Thanks for the effort and time. Strange you got such a different result. Nonetheless, I do see a lot of assumable GUI-related packages on your output too. All *gdk*, *gtk* packages and also "adwaita-icon-theme" just to mention some. Perhaps even all *X* packages. (just forget the 16 packages at 5MB it was just from some an old installation documentation I made from 15.2) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1191246] Package "virt-install" seem to install a lot of GUI packages
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

https://bugzilla.suse.com/show_bug.cgi?id=1191246 https://bugzilla.suse.com/show_bug.cgi?id=1191246#c3 --- Comment #3 from Charles Arnold <carnold(a)suse.com> --- In my testing of Leap 15.3 installing with a minimal server pattern I get the following when doing a 'zypper install --no-recommends virt-install' at the command line. " Loading repository data... Reading installed packages... Resolving package dependencies... The following 55 NEW packages are going to be installed: adwaita-icon-theme at-spi2-core gdk-pixbuf-loader-rsvg gdk-pixbuf-query-loaders gtk3-data gtk3-schema gtk3-tools libXcomposite1 libXcursor1 libXdamage1 libXfixes3 libXi6 libXinerama1 libXrandr2 libXtst6 libappindicator3-1 libatk-1_0-0 libatk-bridge-2_0-0 libatspi0 libcairo-gobject2 libcolord2 libcroco-0_6-3 libdbusmenu-glib4 libdbusmenu-gtk3-4 libepoxy0 libgdk_pixbuf-2_0-0 libgtk-3-0 libindicator3-7 libjson-glib-1_0-0 libosinfo libosinfo-1_0-0 librest-0_7-0 librsvg-2-2 libsoup-2_4-1 libssh2-1 libvirt-glib-1_0-0 libvirt-libs libwayland-client0 libwayland-cursor0 libwayland-egl1 libxkbcommon0 osinfo-db python3-ipaddr python3-libvirt-python python3-libxml2-python typelib-1_0-AppIndicator3-0_1 typelib-1_0-Atk-1_0 typelib-1_0-GdkPixbuf-2_0 typelib-1_0-Gtk-3_0 typelib-1_0-Libosinfo-1_0 typelib-1_0-LibvirtGLib-1_0 typelib-1_0-Pango-1_0 virt-install virt-manager-common xkeyboard-config 55 new packages to install. Overall download size: 24.2 MiB. Already cached: 0 B. After the operation, additional 78.9 MiB will be used. Continue? [y/n/v/...? shows all options] (y): " This is much smaller than what you are seeing although still much larger than 16 packages at 5 MB on some unspecified older version. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175642] New: libvirtd crashes when stopped
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1175642 Bug ID: 1175642 Summary: libvirtd crashes when stopped Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: ralf.koelmel(a)kit.edu QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 840947 --> http://bugzilla.opensuse.org/attachment.cgi?id=840947&action=edit stacktrace of the crash the libvirtd daemon from libvirt-daemomon (version 6.0.0-lp152.8.1) is replicably crashing during stopping. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1191347] New: Yast2 Disk masks all systemd x.mount units
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1191347 Bug ID: 1191347 Summary: Yast2 Disk masks all systemd x.mount units Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: All OS: openSUSE Leap 15.3 Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: itteam(a)smartodds.co.uk QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 852942 --> http://bugzilla.opensuse.org/attachment.cgi?id=852942&action=edit journal We've come across an issue whereby opening yast2 disk management causes all systemd x.mount units to be masked until reboot or manual intervention. On some systems this is causing issues restarting services which depend on these (eg nrpe with After=var-run.mount), which present an error: Failed to restart nrpe.service: Unit var.mount is masked. It's simple enough to trigger the masking with yast2 disk as follows. 1. Boot system, confirm var.mount for example is not masked: # systemctl status var.mount �� var.mount - /var Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Tue 2021-10-05 17:17:26 BST; 1min 31s ago Where: /var What: /dev/mapper/vg_system-lv_var Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 (limit: 7030) CGroup: /system.slice/var.mount Oct 05 17:17:25 someserver1 systemd[1]: Mounting /var... Oct 05 17:17:26 someserver1 systemd[1]: Mounted /var. 2. Run yast2 disk > sudo yast2 disk 3. Accept the warning prompt and proceed to Abort or Finish without making any changes. 4. Check the status again of var.mount and find that it is masked (note the log of changed status, this was achieved setting journalctl to debug mode with systemctl log-level debug): # systemctl status var.mount �� var.mount - /var Loaded: masked (Reason: Unit var.mount is masked.) Active: active (mounted) since Tue 2021-10-05 17:17:26 BST; 2min 50s ago Where: /var What: /dev/mapper/vg_system-lv_var Tasks: 0 (limit: 7030) CGroup: /system.slice/var.mount Oct 05 17:17:25 someserver1 systemd[1]: Mounting /var... Oct 05 17:17:26 someserver1 systemd[1]: Mounted /var. Oct 05 17:19:26 someserver1 systemd[1]: var.mount: Changed dead -> mounted Oct 05 17:19:37 someserver1 systemd[1]: var.mount: Changed dead -> mounted 5. It's actually masking every mount unit it seems: # ll /run/systemd/system total 0 lrwxrwxrwx 1 root root 9 Oct 5 17:19 \x2esnapshots.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 backup.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 boot-grub2-i386\x2dpc.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 boot-grub2-x86_64\x2defi.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 data.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 dev-disk-by\x2did-dm\x2dname\x2dvg_system\x2dlv_swap.swap -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 dev-disk-by\x2did-dm\x2duuid\x2dLVM\x2dNn2wUiPvm30gKUVSZzdj7ZcrG3W8F0qgJkggHvpUF2wzkNeQpQmB1Vb4sk6o43zY.swap -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 dev-disk-by\x2duuid-61a850a3\x2de6cd\x2d4156\x2dbdfe\x2d59c040afdf8d.swap -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 dev-dm\x2d0.swap -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 dev-mapper-vg_system\x2dlv_swap.swap -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 dev-vg_system-lv_swap.swap -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 home.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 opt.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 root.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 srv.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 tmp.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 usr-local.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 var-lock.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 var-run.mount -> /dev/null lrwxrwxrwx 1 root root 9 Oct 5 17:19 var.mount -> /dev/null 6. At this point the service cannot be restarted: # systemctl restart nrpe Failed to restart nrpe.service: Unit var.mount is masked. Either rebooting, or removing the symlink and doing a daemon reload is sufficient to resolve individual units, in this case nrpe also needs tmp.mount (possibly due to the PrivateTmp=true directive): # rm /run/systemd/system/var.mount # systemctl daemon-reload # systemctl restart nrpe Failed to restart nrpe.service: Unit tmp.mount is masked. # rm /run/systemd/system/tmp.mount # systemctl daemon-reload # systemctl restart nrpe (starts fine) This latter behaviour though is where there is a divergence, the service will only fail to restart on *some* systems, despite the unit file (/usr/lib/systemd/system/nrpe.service) being identical and all systems seeing the same masking behaviour triggered by yast. So a few questions are raised, namely why is yast2 disk masking the x.mount units, is this expected, and is it supposed to leave them in this state? But then also why is it only having a tangible effect on some systems? Attached is the systemd journal (debug level). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1187399] New: /run/libvirt does not exist => libvirtd.service fails to start
by bugzilla_noreply＠suse.com 05 Oct '21

05 Oct '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1187399 Bug ID: 1187399 Summary: /run/libvirt does not exist => libvirtd.service fails to start Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: michael(a)stroeder.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since a recent Tumbleweed snapshot the run-time directory is not present and thus libvirtd.service fails to start. Manually creating the directory makes it work again: mkdir /run/libvirt ; systemctl restart libvirtd -- You are receiving this mail because: You are on the CC list for the bug.

1 1