June 2021 - openSUSE Support - openSUSE Mailing Lists

Re: zypper patch about to uninstall half (all?) of leap 15.3 installation?
by -pj 09 Jun '21

09 Jun '21

On 6/8/21 11:14 AM, cagsm wrote: > On Tue, Jun 8, 2021 at 5:39 PM Marcus Meissner <meissner(a)suse.de> wrote: >> Update ... this is still work in progress, I hope I will get through most of the issues >> this week. > thanks for keeping us informed here. Today some auto update of the > zypp/libzypp stack came along. >> libzypp-17.26.0-9.1.x86_64.rpm installed ok >> zypper-1.14.45-10.1.x86_64.rpm installed ok > > Right now the zypper patch has some different conflicts, but fewer: > === > zypper patch > Loading repository data... > Reading installed packages... > Patch 'SUSE-2021-1847-1' is optional. Use 'zypper in > patch:SUSE-2021-1847' to install it, or '--with-optional' to include > all optional patches. > Resolving package dependencies... > 12 Problems: > Problem: the to be installed patch:SUSE-2020-3304-1.noarch conflicts > with 'libi2c0.x86_64 < 4.0-4.3.2' provided by the installed > libi2c0-4.0-bp153.2.13.x86_64 > Problem: the to be installed patch:SUSE-2020-3792-1.noarch conflicts > with 'gzip.x86_64 < 1.10-4.3.1' provided by the installed > gzip-1.10-3.11.1.x86_64 > Problem: the to be installed patch:SUSE-2021-76-1.noarch conflicts > with 'SUSEConnect.x86_64 < 0.3.29-3.34.1' provided by the installed > SUSEConnect-0.3.29-3.6.1.x86_64 > Problem: the to be installed patch:SUSE-2021-510-1.noarch conflicts > with 'ucode-intel.x86_64 < 20210216-3.64.1' provided by the installed > ucode-intel-20210216-2.19.1.x86_64 > Problem: the to be installed patch:SUSE-2021-931-1.noarch conflicts > with 'libnghttp2-14-32bit.x86_64 < 1.40.0-3.11.1' provided by the > installed libnghttp2-14-32bit-1.40.0-3.5.1.x86_64 > Problem: the to be installed patch:SUSE-2021-1235-1.noarch conflicts > with 'numactl.x86_64 < 2.0.14-4.3.1' provided by the installed > numactl-2.0.14-1.1.x86_64 > Problem: the to be installed patch:SUSE-2021-1499-1.noarch conflicts > with 'webkit2gtk-4_0-injected-bundles.x86_64 < 2.32.0-3.74.1' provided > by the installed webkit2gtk-4_0-injected-bundles-2.32.0-3.15.1.x86_64 > Problem: the installed libx265-169-3.0-lp150.1.6.x86_64 requires > 'libnuma.so.1()(64bit)', but this requirement cannot be provided > Problem: the to be installed patch:SUSE-2020-3129-1.noarch conflicts > with 'sysconfig-netconfig.x86_64 < 0.85.6-3.6.1' provided by the > installed sysconfig-netconfig-0.85.6-3.3.1.x86_64 > Problem: the to be installed patch:SUSE-2021-1200-1.noarch conflicts > with 'libreoffice-writer-extensions.x86_64 < 7.1.2.2-13.15.1' provided > by the installed libreoffice-writer-extensions-7.1.2.2-2.3.x86_64 > Problem: the to be installed patch:SUSE-2021-1569-1.noarch conflicts > with 'libreoffice-writer.x86_64 < 7.1.3.2-13.18.3' provided by the > installed libreoffice-writer-7.1.2.2-2.3.x86_64 > Problem: the installed zypper-search-packages-plugin-0.7-5.35.noarch > requires 'rubygem(ruby:2.5.0:suse-connect) >= 0.3.9', but this > requirement cannot be provided > > Problem: the to be installed patch:SUSE-2020-3304-1.noarch conflicts > with 'libi2c0.x86_64 < 4.0-4.3.2' provided by the installed > libi2c0-4.0-bp153.2.13.x86_64 > Solution 1: Following actions will be done: > deinstallation of libi2c0-4.0-bp153.2.13.x86_64 > deinstallation of i2c-tools-4.0-bp153.2.13.x86_64 > Solution 2: do not install patch:SUSE-2020-3304-1.noarch > > Choose from above solutions by number or skip, retry or cancel > [1/2/s/r/c/d/?] (c): > === > > should we still wait with zypper patch and zypper in general? > ty. Eventually will a "being/entity" who navigates a machine. Sometimes updating - it's funny with "zypper patch" and then ask about "zypper in general". See you around bigtimers. :|

2 1

xsane--setup
by Douglas McGarrett 09 Jun '21

09 Jun '21

Hope someone out there is familiar with xsane, a scanner driver that works on Linux and on OpenSUSE. I want to use this because it allows print pixel density, save in various sizes and modes, etc. Installed it using Yast zypper. (I had it working once on Tumbleweed--don't remember what hoops I had to go thru, but it was simpler than now.) Running Leap 15.3 (Carlos take note!) Xsane website shows that it is completely compatible with Epson WP4530 all-mode-printer-scanner-fax. (I have had xsane running on Linux since PCLOS, 9 or more years ago, with the same scanner hardware.) Changed address in /etc/sane.d/epson2.conf to reflect the fixed IP address of the /printer-scanner. Computer says Points to usr/share/applications/xsane.desktop --I don't remember the "desktop" addition to the filename Also, under permissions, says file is a link and does not have permissions. Thanx for any assistance--doug

3 5

zypper patch about to uninstall half (all?) of leap 15.3 installation?
by cagsm 07 Jun '21

07 Jun '21

Is this why the wait until this weekend (is over?) to not use zypper patch according to 15.3 releasenotes? === sudo zypper lp Loading repository data... Reading installed packages... Repository | Name | Category | Severity | Interactive | Status | Since | Summary -------------------------------------------------------------+----------------+-------------+-----------+-------------+--------+-------+---------------------------- Update repository with updates from SUSE Linux Enterprise 15 | SUSE-2021-1526 | recommended | important | --- | needed | - | Recommended update for bash === sudo zypper patch Loading repository data... Reading installed packages... Resolving package dependencies... Problem: patch:SUSE-2021-1526-1.noarch conflicts with readline-doc < 7.0-19.3.1 provided by readline-doc-7.0-17.83.noarch Solution 1: Following actions will be done: deinstallation of readline-doc-7.0-17.83.noarch deinstallation of readline-devel-7.0-17.83.x86_64 deinstallation of libreadline7-7.0-17.83.x86_64 deinstallation of bash-lang-4.4-17.83.noarch deinstallation of bash-doc-4.4-17.83.noarch deinstallation of kernel-default-optional-5.3.18-56.2.x86_64 deinstallation of kernel-default-extra-5.3.18-56.2.x86_64 deinstallation of kernel-default-5.3.18-56.2.x86_64 deinstallation of bash-4.4-17.83.x86_64 .............. tons more ty

3 3

Preventing loading of nvidia kernel module(s)
by J Leslie Turriff 04 Jun '21

04 Jun '21

I'm trying to set up my nvidia graphics card for dedication to a virtual machine, as described in "VGA PCI Passthrough guide on openSUSE Leap 42.2" https://forums.opensuse.org/showthread.php/522015-VGA-PCI-Passthrough-guide… and though I've followed all of the steps, when I get to step 6 (Reboot and check that your GPU was isolated) I see | ● lspci -k|grep -i nvidia | 01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2060] (rev a1) | Kernel driver in use: nvidia | Kernel modules: nouveau, nvidia_drm, nvidia | @14:46:53,root@pinto rc=0 instead of "Kernel driver in use: vfio-pci". When I use lsmod to scan for "nvidia" or "nouveau" I get | ● modprobe -c|grep -e nvidia -e nouveau|grep -v alias | blacklist nvidiafb | blacklist nouveau | install nvidia PATH=$PATH:/bin:/usr/bin; if /sbin/modprobe --ignore-install nvidia; then if ... fi; fi | options nvidia NVreg_DynamicPowerManagement=0x01 | options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=482 NVreg_DeviceFileMode=0660 | @14:51:12,root@pinto rc=0 Looking at the zypper database, I see that I must have installed the nvidia proprietary driver some time in the past. | ● zypper se -i nvidia | Loading repository data... | Reading installed packages... | | S | Name | Summary | Type | --+---------------------------+-----------------------------------------------------------------------+-------- | i | nvidia-computeG05 | NVIDIA driver for computing with GPGPU | package | i | nvidia-gfxG05-kmp-default | NVIDIA graphics driver kernel module for GeForce 600 series and newer | package | i | nvidia-glG05 | NVIDIA OpenGL libraries for OpenGL acceleration | package | i | x11-video-nvidiaG05 | NVIDIA graphics driver for GeForce 600 series and newer | package | @14:54:32,root@pinto rc=0 Will removing these packages be sufficient to isolate the graphics card, or will further steps be necessary? Leslie -- openSUSE Leap 15.2 x86_64

2 1

Leap 15.3 and new update repositories
by Till Dörges 03 Jun '21

03 Jun '21

Hello all, I just set up a 15.3 test machine from scratch. Yesterday installing updates via 'zypper dup' gave me a new repo key to accept and new repos (see below). That raised two questions: o How can I verify the newly introduced key? In terms of crypto usability it doesn't seem like an ideal approach to introduce new trust anchors (i.e. new repo keys) w/o clearly documenting how to verify that it is actually legitimate. o Do I need the new update repos (repo-backports-update, repo-sle-update)? And if so, what's the difference to the previous update repos? Before the update there were only repo-update and repo-update-non-oss. leap153:~ # zypper up Retrieving repository 'Update repository of openSUSE Backports' metadata -----------------------------------------[\] New repository or package signing key received: Repository: Update repository of openSUSE Backports Key Name: openSUSE:Backports OBS Project <openSUSE:Backports@build.opensuse.org> Key Fingerprint: 637B32FF 3D83F07A 7AE1C40A 9C214D40 65176565 Key Created: Wed Oct 2 15:17:53 2019 Key Expires: Fri Dec 10 14:17:53 2021 Rpm Name: gpg-pubkey-65176565-5d94a381 user@leap153:~> zypper lr # | Alias | Name | Enabled | GPG Check | Refresh ---+-----------------------------+---------------------------------------------------------------------------------------------+-----------+-----------------+--------------- [...] 3 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | Nein | ---- | ---- 4 | repo-backports-update | Update repository of openSUSE Backports | Nein | ---- | ---- 5 | repo-debug | Debug Repository | Nein | ---- | ---- 6 | repo-debug-non-oss | Debug Repository (Non-OSS) | Nein | ---- | ---- 7 | repo-debug-update | Update Repository (Debug) | Nein | ---- | ---- 8 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | Nein | ---- | ---- 9 | repo-non-oss | Non-OSS Repository | Ja | (r ) Ja | Ja 10 | repo-oss | Haupt-Repository | Ja | (r ) Ja | Ja 11 | repo-sle-update | Update repository with updates from SUSE Linux Enterprise 15 | Nein | ---- | ---- 12 | repo-source | Source Repository | Nein | ---- | ---- 13 | repo-source-non-oss | Source Repository (Non-OSS) | Nein | ---- | ---- 14 | repo-update | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja 15 | repo-update-non-oss | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Ja | (r ) Ja | Ja Thanks and regards -- Till -- Dipl.-Inform. Till Dörges doerges(a)pre-sense.de PRESENSE Technologies GmbH Nagelsweg 41, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024 Besuchen Sie uns gerne auf der digitalen Plattform it-sa 365: https://www.itsa365.de/de-de/companies/p/presense-technologies-gmbh

2 2

No IPv6 address in TW
by Bjoern Voigt 02 Jun '21

02 Jun '21

My Tumbleweed system does not get a public IPv6 address. The reason is unknown, but it must be a configuration problem, because all other dual boot OS, TW in rescue mode and even the KVM VMs get an IPv6 address on the same hardware. The router is OpenWrt based and seems to work fine. I already tried to copy the network configuration from the rescue system. I use a Wicked based network configuration, set up with YaST. For privacy reasons I replaced some numbers with "xx". # wicked ifstatus br0 br0 up link: #16, state up, mtu 1454 type: bridge, hwaddr xx:xx:xx:xx:xx:xx config: compat:suse:/etc/sysconfig/network/ifcfg-br0 leases: ipv4 dhcp granted leases: ipv6 dhcp requesting addr: ipv4 192.168.xxx.xxx/24 [dhcp] route: ipv4 default via 192.168.xxx.xxx proto dhcp # cat /etc/sysconfig/network/ifcfg-br0 BOOTPROTO='dhcp' STARTMODE='auto' ZONE='home' BRIDGE='yes' BRIDGE_PORTS='eno1' BRIDGE_STP='on' BRIDGE_FORWARDDELAY='2' # ip -6 addr show br0 16: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1454 qdisc noqueue state UP group default qlen 1000 inet6 fe80::406e:b2ff:fe1d:ae7/64 scope link valid_lft forever preferred_lft forever # systemctl status wickedd-dhcp6.service ● wickedd-dhcp6.service - wicked DHCPv6 supplicant service Loaded: loaded (/usr/lib/systemd/system/wickedd-dhcp6.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2021-05-31 11:37:15 CEST; 53min ago Main PID: 26380 (wickedd-dhcp6) Tasks: 1 (limit: 4915) CPU: 48ms CGroup: /system.slice/wickedd-dhcp6.service └─26380 /usr/libexec/wicked/bin/wickedd-dhcp6 --systemd --foreground May 31 11:37:15 mybox systemd[1]: Starting wicked DHCPv6 supplicant service... May 31 11:37:15 mybox systemd[1]: Started wicked DHCPv6 supplicant service. May 31 11:38:46 mybox wickedd-dhcp6[26380]: br0: Request to acquire DHCPv6 lease with UUID xxxxxxxx-xxxx-xxxx-xxxx-00001a0> May 31 11:47:16 mybox wickedd-dhcp6[26380]: br0: Request to release DHCPv6 lease using UUID xxxxxxxx-xxxx-xxxx-xxxx-00001a> May 31 11:47:33 mybox wickedd-dhcp6[26380]: br0: Request to acquire DHCPv6 lease with UUID xxxxxxxx-xxxx-xxxx-xxxx-0000200> May 31 12:20:04 mybox wickedd-dhcp6[26380]: br0: Request to release DHCPv6 lease using UUID xxxxxxxx-xxxx-xxxx-xxxx-000020> May 31 12:24:43 mybox wickedd-dhcp6[26380]: br0: Request to acquire DHCPv6 lease with UUID xxxxxxxx-xxxx-xxxx-xxxx-0000340> # ping6 www.heise.de ping6: connect: Network is unreachable # sysctl net.ipv6.conf.all.disable_ipv6 net.ipv6.conf.all.disable_ipv6 = 0 # sysctl net.ipv6.conf.all.forwarding net.ipv6.conf.all.forwarding = 1 Any ideas? Greetings, Björn

2 3

Filesystems Confusion
by Robin Klitscher 01 Jun '21

01 Jun '21

After long resisting the idea, I hope to switch from ext4 to btrfs for my next installation, Leap 15.3. The openSUSE norm is btrfs for / and xfs for /home, each in separate partitions, right? But, in contrast as I understand it, it seems Fedora’s default is for a single btrfs partition for both. Why the difference? That is, why a separate /home in Leap? And why xfs rather than btrfs anyway? And a supplementary question. What are the implications if I wanted to use additional data partition(s) besides /home? Should they be in btrfs? Or xfs? Or doesn’t it matter? -- Robin K Wellington "Harbour City" New Zealand

5 9