Zypper slows down the system and bitwarden is down after update

I have two problems since the last TW updates.

The first is that the zypper is very slow and significantly slows down the system to the point of freezing it for several ten seconds.

I had several episodes of corrupted journals with systemd-journald.service without knowing if it was this event that created the problem with zypper. But a ‘rm’ on corrupted logs with a restart ‘’ fixed systemd-journald.service without resolving Zypper’s extreme slowness.

I admit that I didn’t have the presence of mind to take a time to quantify what I said.

I take advantage of the chapter to inform you that I have a lot of errors in green writing to indicate that links to files that do not exist are impossible.
By the way, why are the typing errors during compilations missing already installed files?

My most serious problem concerns Bitwarden which no longer works and displays a white window.

Since everything happened at the same time, I see a connection that may not exist.

I did a clumsy delete operation.

It appears that the nodejs-electron file is in question since it was updated to nodejs-electron-25.8.4-1.1.x86_64 today. This version seems buggy.

It is obviously not possible for me to downgrade with my knowledge to the previous version nodejs-electron-25.8.2-1.1.x86_64.

Ideas

Have you attempted:

  1. To boot using a previous kernel version via grub, then compare/test, or:

  2. Fall back to a previous snapshot, then compare/test (?)

Thank you for your prompt response.

I rolled back 2 days before and Bitwarden still didn’t work.

After a reboot on an older kernel of version 2: 6.5.2-1-default, I was able to fully regain the functional use of Bitwarden.

Thanks, I hadn’t thought about rollback.

I will come back with other information regarding zypper for the older kernel had no benefit.

I started a “time zypper up” an hour ago for 24 packages and I’m only at 4/24.
The evil is deeper.

I will come back with factual and more precise information once the update is complete… in what hours.

Here is the information regarding updating with zypper.

There are also symbolic link errors that have been appearing for several days.
My system still slowed down during the update but to a lesser extent.

# time zypper up Refreshing service 'NVIDIA'. Refreshing service 'openSUSE'. Retrieving repository 'Packman Repository' metadata ...............................................................................................................................[done] Building repository 'Packman Repository' cache ....................................................................................................................................[done] Loading repository data... Reading installed packages...

The following 24 packages are going to be upgraded:
Mesa Mesa-KHR-devel Mesa-devel Mesa-dri Mesa-dri-devel Mesa-gallium Mesa-libEGL-devel Mesa-libEGL1 Mesa-libGL-devel Mesa-libGL1 Mesa-libGLESv1_CM-devel Mesa-libGLESv2-devel
Mesa-libOpenCL Mesa-libRusticlOpenCL Mesa-libglapi-devel Mesa-libglapi0 Mesa-libva Mesa-vulkan-device-select libOSMesa-devel libOSMesa8 libgbm-devel libgbm1 libvdpau_nouveau
libvulkan_intel

24 packages to upgrade.
Overall download size: 46.8 MiB. Already cached: 0 B. After the operation, additional 10.1 MiB will be used.
Continue? [y/n/v/…? shows all options] (y): y
Retrieving: libvdpau_nouveau-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (1/24), 3.8 MiB
Retrieving: libvdpau_nouveau-23.2.0-1699.360.pm.1.x86_64.rpm …[done (1.9 MiB/s)]
Retrieving: Mesa-KHR-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (2/24), 50.6 KiB
Retrieving: Mesa-KHR-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: libgbm1-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (3/24), 81.4 KiB
Retrieving: libgbm1-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-libglapi0-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (4/24), 72.2 KiB
Retrieving: Mesa-libglapi0-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-libRusticlOpenCL-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (5/24), 6.4 MiB
Retrieving: Mesa-libRusticlOpenCL-23.2.0-1699.360.pm.1.x86_64.rpm …[done (2.1 MiB/s)]
Retrieving: Mesa-vulkan-device-select-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (6/24), 59.9 KiB
Retrieving: Mesa-vulkan-device-select-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-libOpenCL-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (7/24), 1.1 MiB
Retrieving: Mesa-libOpenCL-23.2.0-1699.360.pm.1.x86_64.rpm …[done (1.1 MiB/s)]
Retrieving: Mesa-libva-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (8/24), 4.0 MiB
Retrieving: Mesa-libva-23.2.0-1699.360.pm.1.x86_64.rpm …[done (1.9 MiB/s)]
Retrieving: libgbm-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (9/24), 52.0 KiB
Retrieving: libgbm-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done (10.9 KiB/s)]
Retrieving: Mesa-libEGL1-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (10/24), 168.0 KiB
Retrieving: Mesa-libEGL1-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: libOSMesa8-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (11/24), 2.8 MiB
Retrieving: libOSMesa8-23.2.0-1699.360.pm.1.x86_64.rpm …[done (2.6 MiB/s)]
Retrieving: Mesa-libglapi-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (12/24), 47.4 KiB
Retrieving: Mesa-libglapi-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: libvulkan_intel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (13/24), 5.9 MiB
Retrieving: libvulkan_intel-23.2.0-1699.360.pm.1.x86_64.rpm …[done (1.9 MiB/s)]
Retrieving: Mesa-dri-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (14/24), 8.9 MiB
Retrieving: Mesa-dri-23.2.0-1699.360.pm.1.x86_64.rpm …[done (2.2 MiB/s)]
Retrieving: Mesa-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (15/24), 52.1 KiB
Retrieving: Mesa-23.2.0-1699.360.pm.1.x86_64.rpm …[done (1.0 KiB/s)]
Retrieving: Mesa-libGL1-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (16/24), 204.3 KiB
Retrieving: Mesa-libGL1-23.2.0-1699.360.pm.1.x86_64.rpm …[done (196.2 KiB/s)]
Retrieving: Mesa-libEGL-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (17/24), 66.5 KiB
Retrieving: Mesa-libEGL-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done (66.4 KiB/s)]
Retrieving: libOSMesa-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (18/24), 51.5 KiB
Retrieving: libOSMesa-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-libGL-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (19/24), 486.7 KiB
Retrieving: Mesa-libGL-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done (430.9 KiB/s)]
Retrieving: Mesa-gallium-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (20/24), 12.1 MiB
Retrieving: Mesa-gallium-23.2.0-1699.360.pm.1.x86_64.rpm …[done (2.4 MiB/s)]
Retrieving: Mesa-libGLESv1_CM-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (21/24), 60.7 KiB
Retrieving: Mesa-libGLESv1_CM-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-libGLESv2-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (22/24), 81.7 KiB
Retrieving: Mesa-libGLESv2-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-dri-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (23/24), 66.0 KiB
Retrieving: Mesa-dri-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]
Retrieving: Mesa-devel-23.2.0-1699.360.pm.1.x86_64 (Packman Repository) (24/24), 127.9 KiB
Retrieving: Mesa-devel-23.2.0-1699.360.pm.1.x86_64.rpm …[done]

Checking for file conflicts: …[done]
( 1/24) Installing: libvdpau_nouveau-23.2.0-1699.360.pm.1.x86_64 …[done]
( 2/24) Installing: Mesa-KHR-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
( 3/24) Installing: libgbm1-23.2.0-1699.360.pm.1.x86_64 …[done]
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
( 4/24) Installing: Mesa-libglapi0-23.2.0-1699.360.pm.1.x86_64 …[done]
( 5/24) Installing: Mesa-libRusticlOpenCL-23.2.0-1699.360.pm.1.x86_64 …[done]
( 6/24) Installing: Mesa-vulkan-device-select-23.2.0-1699.360.pm.1.x86_64 …[done]
( 7/24) Installing: Mesa-libOpenCL-23.2.0-1699.360.pm.1.x86_64 …[done]
( 8/24) Installing: Mesa-libva-23.2.0-1699.360.pm.1.x86_64 …[done]
( 9/24) Installing: libgbm-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
(10/24) Installing: Mesa-libEGL1-23.2.0-1699.360.pm.1.x86_64 …[done]
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
(11/24) Installing: libOSMesa8-23.2.0-1699.360.pm.1.x86_64 …[done]
(12/24) Installing: Mesa-libglapi-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(13/24) Installing: libvulkan_intel-23.2.0-1699.360.pm.1.x86_64 …[done]
(14/24) Installing: Mesa-dri-23.2.0-1699.360.pm.1.x86_64 …[done]
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
(15/24) Installing: Mesa-23.2.0-1699.360.pm.1.x86_64 …[done]
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib/libhid.so.0 is not a symbolic link
/sbin/ldconfig: /lib64/libhid.so.0.0 is for unknown machine 40.
/sbin/ldconfig: /lib64/libhid.so.0 is not a symbolic link
(16/24) Installing: Mesa-libGL1-23.2.0-1699.360.pm.1.x86_64 …[done]
(17/24) Installing: Mesa-libEGL-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(18/24) Installing: libOSMesa-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(19/24) Installing: Mesa-libGL-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(20/24) Installing: Mesa-gallium-23.2.0-1699.360.pm.1.x86_64 …[done]
(21/24) Installing: Mesa-libGLESv1_CM-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(22/24) Installing: Mesa-libGLESv2-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(23/24) Installing: Mesa-dri-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
(24/24) Installing: Mesa-devel-23.2.0-1699.360.pm.1.x86_64 …[done]
There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run ‘zypper ps -s’ to list these programs.

real 37m3.937s
user 0m6.566s
sys 0m1.928s

As the last output doesn‘t show why or where the most time is used…
Some general checks:

  • which packman mirror is used? Try another one…
  • do you need all the devel packages?
  • is there enough space left on your HDD/SSD?
  • where is libhid.so.0 coming from? Seems not like an openSUSE package…
ich@rennsemmel:~> LC_ALL=C zypper se --provides libhid.so.0
Loading repository data...
Reading installed packages...
No matching items found.
ich@rennsemmel:~> 

Did you take a look at, the amount of disk space the systemd Journal has been using?

 # journalctl --disk-usage 
Archived and active journals take up 496.0M in the file system.
 #

For the partition where the systemd journals are located, did you take a look at the partition’s of free space?

 > LANG=C df --human-readable /var/log/journal/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        16G  2.9G   12G  20% /var
 >

And, please do not use “rm” to clean up the amount of space the systemd Journal is using –

  • Please, use the systemd Journal tool-box.
 # journalctl --verify
 # journalctl --vacuum-size=3G
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal/02d4bd6562f443dc87a4204963c403f6.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
 # journalctl --vacuum-files=50
Vacuuming done, freed 0B of archived journals from /var/log/journal/02d4bd6562f443dc87a4204963c403f6.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
 # journalctl --vacuum-time=6months
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal/02d4bd6562f443dc87a4204963c403f6.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
 #

Given that, Bitwarden is freemium open-source password management service and, there doesn’t seem to be a related package in the openSUSE repositories, you may have to contact Bitwarden Inc. for support.


Please be aware that, if, you haven’t been taking backups of your password keys (such backups have to be stored on a removable device which you normally keep locked away in a physically safe place), you’ll probably experience some pain if you have to reinstall that application …

@hui
your commande :

LC_ALL=C zypper se --provides libhid.so.0
Refreshing service ‘NVIDIA’.
Refreshing service ‘openSUSE’.
Loading repository data…
Reading installed packages…
No matching items found.

my default repositories which were updated with kernel 6.5 :

zypper lr Repository priorities are without effect. All enabled repositories share the same priority.

| Alias | Name | Enabled | GPG Check | Refresh

—±---------------------------------------±---------------------±--------±----------±-------
1 | NVIDIA:repo-non-free | repo-non-free | Yes | (r ) Yes | Yes
2 | brave | brave | Yes | (r ) Yes | Yes
3 | ftp.gwdg.de-openSUSE_Tumbleweed | Packman Repository | Yes | (r ) Yes | Yes
4 | openSUSE:repo-non-oss | repo-non-oss | Yes | (r ) Yes | Yes
5 | openSUSE:repo-openh264 | repo-openh264 | Yes | (r ) Yes | Yes
6 | openSUSE:repo-oss | repo-oss | Yes | (r ) Yes | Yes
7 | openSUSE:repo-oss-debug | repo-oss-debug | No | ---- | ----
8 | openSUSE:repo-oss-source | repo-oss-source | No | ---- | ----
9 | openSUSE:update-tumbleweed | update-tumbleweed | Yes | (r ) Yes | Yes
10 | opensuse-guide.org-openSUSE_Tumbleweed | libdvdcss repository | Yes | (r ) Yes | Yes
11 | vscode | vscode | Yes | (r ) Yes | Yes

@dcurtisfra

journalctl --disk-usage
Archived and active journals take up 196.9M in the file system.

and

LANG=C df --human-readable /var/log/journal/
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 883G 551G 329G 63% /var

General remarks.

Please use the “Preformatted text” feature of the forums posting software. It is the button </> in the toolbar of the post editor. Select your copied/pasted computer text and hit that button.

Please when you want to inform us about a repository list, then use a command that provides the URLs, like

zypper lr -d

Now we have only Names and Aliases that are local to your system. They may hint to what the repos are, but we are not sure.

@hcvv

zypper lr -d
#  | Alias                                  | Name   | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                 | Service
---+----------------------------------------+--------+---------+-----------+---------+----------+--------+---------------------------------------------------------------------+---------
 1 | NVIDIA:repo-non-free                   | repo-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | https://download.nvidia.com/opensuse/tumbleweed/                    | NVIDIA
 2 | brave                                  | brave  | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | https://brave-browser-rpm-release.s3.brave.com/x86_64/              | 
 3 | ftp.gwdg.de-openSUSE_Tumbleweed        | Pack-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/ | 
 4 | openSUSE:repo-non-oss                  | repo-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://cdn.opensuse.org/tumbleweed//repo/non-oss                    | openSUSE
 5 | openSUSE:repo-openh264                 | repo-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed             | openSUSE
 6 | openSUSE:repo-oss                      | repo-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://cdn.opensuse.org/tumbleweed//repo/oss                        | openSUSE
 7 | openSUSE:repo-oss-debug                | repo-> | No      | ----      | ----    |   99     | NONE   | http://cdn.opensuse.org/debug/tumbleweed//repo/oss                  | openSUSE
 8 | openSUSE:repo-oss-source               | repo-> | No      | ----      | ----    |   99     | NONE   | http://cdn.opensuse.org/source/tumbleweed//repo/oss                 | openSUSE
 9 | openSUSE:update-tumbleweed             | upda-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://cdn.opensuse.org/update/tumbleweed/                          | openSUSE
10 | opensuse-guide.org-openSUSE_Tumbleweed | libd-> | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://opensuse-guide.org/repo/openSUSE_Tumbleweed/                 | 
11 | vscode                                 | vscode | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | https://packages.microsoft.com/yumrepos/vscode

Aren’t those CDN addresses a possible source of the problem?
I leave to those who know something about this CDN usage in openSUSE to comment.

@hcvv
This is from the 6.5 kernel update.

There was an option informing me that the repositories were going to be updated automatically and the Nvidia driver was compiled without me being asked about this modification.

Besides, there are a lot of errors dracut asks for “menstrack” (from memory) and it is not installed. Same for other modules.
I checked with Yast, they are all installed.

It is completely normal that dracut informs you about missing modules. Only the necessary modules which are needed to talk with your hardware/(software) are installed and used by dracut. All other modules which are not needed for your hardware/(software), are not installed and dracut only issues an informational message whilst building initrd.

At a guess, your system uses the Btrfs filesystem for the system directories and therefore, the Btrfs filesystem command is better suited to determine the amount of free space available –

> btrfs filesystem df --human-readable /var/log/journal/

Even so, it seems that, there’s enough free space on the filesystem used by the system –

  • Therefore, probably not the cause of your performance issue.

@dcurtisfra
That’s what I think too with 352 GB free.

btrfs filesystem df --human-readable /var/log/journal/

Data, single: total=546.01GiB, used=541.85GiB
System, DUP: total=32.00MiB, used=80.00KiB
Metadata, DUP: total=6.00GiB, used=4.16GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

I installed Bitwarden with zypper

zypper se bitwarden
Refreshing service 'NVIDIA'.
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...

S  | Name      | Summary                                                    | Type
---+-----------+------------------------------------------------------------+--------
i+ | bitwarden | A secure and free password manager for all of your devices | package

@straight_ahead:

To analyse where the Zypper update (zypper up) took time, you’ll have to inspect the contents of ‘/var/log/zypp/history’ …


But, you’re using Tumbleweed –

  • Therefore, no patches, no updates

  • Only, distribution upgrades

Therefore –

 # zypper dist-upgrade
 # zypper dup

Could it simply be that, you forgot to include a “d” before the “up”?

Good catch!

I may be over 70 with both eyes fitted out with artificial lenses due to cataract operations but, some things simply jump out at you – after a while … :smiling_imp: