OpenSUSE Tumbleweed: Zypper dup hangs at installation of package

Hello! I have been having this problem for around a week now, but every time that I try to update openSUSE using zypper dup, zypper hangs at the installation of a package. When zypper hangs, it does not allow me to quit the program (necessitating a restart) or open a new tty. There is no consistency regarding which package it happens at so far as I can tell. This is the terminal output from the command:

(108/333) Installing: kernel-devel-6.9.7-1.1.noarch ...................................................... [done]
(109/333) Installing: libXcursor1-1.2.2-1.2.x86_64 -----------------------------------------------[|]

Here is /var/log/zypper.log:

2024-07-03 17:09:13 <1> localhost.localdomain(1847) [zypp] ReferenceCounted(@0x56287ba06860<=1){0x56287ba18a60}{kernel-devel-6.9.7-1.1} from /var/cache/zypp/packages/openSUSE:repo-oss/noarch/kernel-devel-6.9.7-1.1.noarch.rpm
2024-07-03 17:09:13 <1> localhost.localdomain(1847) [librpmDb] RpmDb::installPackage(/var/cache/zypp/packages/openSUSE:repo-oss/noarch/kernel-devel-6.9.7-1.1.noarch.rpm,0x0000010c)
2024-07-03 17:09:13 <1> localhost.localdomain(1847) [zypp::exec++] Executing[C] 'rpm' '--root' '/' '--dbpath' '/usr/lib/sysimage/rpm' '--define' '_dump_posttrans 1' '-i' '--percent' '--noglob' '--force' '--nodeps' '--' '/var/cache/zypp/packages/openSUSE:repo-oss/noarch/kernel-devel-6.9.7-1.1.noarch.rpm'
2024-07-03 17:09:13 <1> localhost.localdomain(1847) [zypp::exec++] pid 3193 launched
2024-07-03 17:09:13 <1> localhost.localdomain(1847) [Progress++] {#109|Installing: kernel-devel-6.9.7-1.1.noarch} START
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [zypp::exec++] Pid 3193 successfully completed
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [zypp::posttrans] COLLECT 2 dump_posttrans lines
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [Progress++] {#109|Installing: kernel-devel-6.9.7-1.1.noarch} END
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [zypp-core] unlink /var/cache/zypp/packages/openSUSE:repo-oss/noarch/kernel-devel-6.9.7-1.1.noarch.rpm
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [zypp] ReferenceCounted(@0x56287ba11f40<=1){0x562876870c50}{libXcursor1-1.2.2-1.2} from /var/cache/zypp/packages/openSUSE:repo-oss/x86_64/libXcursor1-1.2.2-1.2.x86_64.rpm
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [librpmDb] RpmDb::installPackage(/var/cache/zypp/packages/openSUSE:repo-oss/x86_64/libXcursor1-1.2.2-1.2.x86_64.rpm,0x0000000c)
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [zypp::exec++] Executing[C] 'rpm' '--root' '/' '--dbpath' '/usr/lib/sysimage/rpm' '--define' '_dump_posttrans 1' '-U' '--percent' '--noglob' '--force' '--nodeps' '--' '/var/cache/zypp/packages/openSUSE:repo-oss/x86_64/libXcursor1-1.2.2-1.2.x86_64.rpm'
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [zypp::exec++] pid 3221 launched
2024-07-03 17:09:18 <1> localhost.localdomain(1847) [Progress++] {#110|Installing: libXcursor1-1.2.2-1.2.x86_64} START

I have been searching for a solution to this for some time, but haven’t had any luck. Does anyone here know how I can solve this issue?

First of all, welcome.
Does the log end at this point?
Have you tried upgrading from a virtual terminal?
Please, show the output of these commands:

lsblk -f
df -ah

Sometimes with inexplicable packaging trouble develops, the following helps:

sudo rpm --rebuilddb

Yes, it does.

└─sda1 btrfs              931afed5-a589-4ccd-87e2-a9aeebdd9191  921.6G     1% /var
├─sdb1 vfat   FAT32       54DF-1995                             505.1M     1% /boot/efi
└─sdb2 btrfs              931afed5-a589-4ccd-87e2-a9aeebdd9191                
└─sdg1 vfat   FAT32       D436-BFD3                                           
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       932G  8.7G  922G   1% /
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
devpts             0     0     0    - /dev/pts
sysfs              0     0     0    - /sys
securityfs         0     0     0    - /sys/kernel/security
cgroup2            0     0     0    - /sys/fs/cgroup
pstore             0     0     0    - /sys/fs/pstore
efivarfs        256K  223K   29K  89% /sys/firmware/efi/efivars
bpf                0     0     0    - /sys/fs/bpf
proc               0     0     0    - /proc
tmpfs           1.6G  9.3M  1.6G   1% /run
systemd-1          -     -     -    - /proc/sys/fs/binfmt_misc
debugfs            0     0     0    - /sys/kernel/debug
tracefs            0     0     0    - /sys/kernel/tracing
mqueue             0     0     0    - /dev/mqueue
tmpfs           3.9G     0  3.9G   0% /tmp
hugetlbfs          0     0     0    - /dev/hugepages
configfs           0     0     0    - /sys/kernel/config
fusectl            0     0     0    - /sys/fs/fuse/connections
/dev/sda1       932G  8.7G  922G   1% /.snapshots
/dev/sda1       932G  8.7G  922G   1% /boot/grub2/i386-pc
/dev/sda1       932G  8.7G  922G   1% /home
/dev/sda1       932G  8.7G  922G   1% /root
/dev/sda1       932G  8.7G  922G   1% /srv
/dev/sda1       932G  8.7G  922G   1% /opt
/dev/sda1       932G  8.7G  922G   1% /usr/local
/dev/sda1       932G  8.7G  922G   1% /boot/grub2/x86_64-efi
/dev/sda1       932G  8.7G  922G   1% /var
/dev/sdb1       511M  5.9M  506M   2% /boot/efi
tmpfs           785M  4.0K  785M   1% /run/user/1000
/dev/sdg1        30G   12G   19G  38% /mnt
binfmt_misc        0     0     0    - /proc/sys/fs/binfmt_misc

Thank you for your suggestion, but unfortunately, that did not solve the issue.

Might you be able to clarify what you mean by ‘virtual terminal’? If you are referring to a tty, then yes, that is waht I have been using.

You may need to boot installation or other media for rescue boot to run btrfs check on sda1 and/or sdb2.

Weird, your sda1 and sdb2 have the same UUID. Can you check what is this sdb2?
At least you’re plenty of free space. :slightly_smiling_face:

I didn’t notice the matching UUIDs. I don’t use BTRFS, so can’t check, but I suppose it could be a consequence of using df for BTRFS instead of a BTRFS tool.

I will try this when i get the chance.

The matching UUIDs are because I set up 2 drives in a RAID1 configuration using btrfs.

I ran that, should I put the output here, I’m not entirely sure what I’m looking for…

Additionally, run these to check if your storage really has free space.

btrfs fi show
btrfs fi df /
btrfs fi usage /