How to solve "posttrans scripts skipped while aborting"... if necessary

Hi all,
I am back from 15 days of vacation and today I updated my TW. I had nearly 1.8Gb of updates, but it did not occur to me to check available disk space as I usually have plenty.
So, during the update (in the applying phase) I ran out of space, but I did not immediately recognize the condition because the error message was not very clear (cpio rename error or something like that).

After a few retries I aborted the update, which gave me the following message:

Avvertenza: %posttrans scripts skipped while aborting:    
    xfsprogs-4.9.0-2.2.x86_64.rpm
    thin-provisioning-tools-0.7.0-2.2.x86_64.rpm
    kmod-24-1.1.x86_64.rpm
    e2fsprogs-1.43.4-1.5.x86_64.rpm
    coreutils-8.27-2.3.x86_64.rpm
    ucode-intel-20170707-3.1.x86_64.rpm
    cryptsetup-1.7.5-1.4.x86_64.rpm
    btrfsprogs-4.10.2-2.2.x86_64.rpm
    blog-2.18-4.3.x86_64.rpm
    noto-emoji-fonts-20161025-2.1.noarch.rpm
    noto-coloremoji-fonts-20161025-2.1.noarch.rpm
    grub2-i386-pc-2.02-4.2.x86_64.rpm
    libopenblas_pthreads0-0.2.19-2.8.x86_64.rpm
    libcblas3-20110120-2.8.x86_64.rpm
    libblas3-3.5.0-8.2.x86_64.rpm
    java-1_8_0-openjdk-headless-1.8.0.141-1.1.x86_64.rpm
    python2-Automat-0.6.0-1.1.noarch.rpm
    kbd-2.0.3-4.3.x86_64.rpm
    grub2-x86_64-efi-2.02-4.2.x86_64.rpm
    liblapack3-3.5.0-8.2.x86_64.rpm
    openSUSE-release-20170729-1.2.x86_64.rpm
    xterm-327-2.4.x86_64.rpm
    dbus-1-1.10.20-1.2.x86_64.rpm
    udev-234-2.1.x86_64.rpm
    open-iscsi-2.0.874-34.2.x86_64.rpm
    haveged-1.9.1-13.5.x86_64.rpm
    dmraid-1.0.0.rc16-38.3.x86_64.rpm
    device-mapper-1.02.141-2.1.x86_64.rpm
    dracut-044.1-2.1.x86_64.rpm
    lvm2-2.02.172-2.1.x86_64.rpm
    apache2-2.4.26-1.2.x86_64.rpm
    mdadm-4.0-1.3.x86_64.rpm
    man-2.7.6-3.3.x86_64.rpm
    apache2-prefork-2.4.26-1.2.x86_64.rpm
    virtualbox-host-kmp-default-5.1.24_k4.11.8_2-1.1.x86_64.rpm
    libreoffice-icon-theme-galaxy-5.4.0.3-1.1.noarch.rpm
    libreoffice-icon-theme-breeze-5.4.0.3-1.1.noarch.rpm
    libreoffice-icon-theme-sifr-5.4.0.3-1.1.noarch.rpm
    libreoffice-icon-theme-hicontrast-5.4.0.3-1.1.noarch.rpm
    libreoffice-l10n-en-5.4.0.3-1.1.noarch.rpm

After deleting a few snapshots and rebalancing btrfs, I was able to complete the update by reissuing the “zypper dup” command.
However, the new output did not say anything about posttrans scripts. Now I am wondering if the posttrans scripts the were aborted have been run when reissuing “zypper dup” or not.
How do I check? How do I fix the problem (if there is one)?

Thank you in advance.

Cris

Those scripts are required to run after a package is installed. The are included in the RPM and it is also defined in the RPM should run. Thus as you re-installed those packages/RPMs (which is what happens during an update), those scripts are run again.

Thank you Henk, that solved my problem!

Cris

You are welcome / Prego.

Just thought I share some experience having the same problem but slightly more complicated. It happened today during zypper dup and exactly when it was installing some crucial rpms for zypper and rpm itself.

After that I got this:

# zypper dup
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
zypper: symbol lookup error: /usr/lib64/libzypp.so.1600: undefined symbol: addMacro

Solution was to force installation of the rpms for libsolv-tools, libzypp and zypper.

Like so:
rpm --force -hiv <rpm that you need>

In my case I had downloaded the rpms in advance and could install them from cache

rpm --force -hiv /var/cache/zypp/packages/repo-oss/x86_64/libsolv-tools-0.6.35-1.1.x86_64.rpm
rpm --force -hiv /var/cache/zypp/packages/repo-oss/x86_64/libzypp-17.6.2-1.1.x86_64.rpm
rpm --force -hiv /var/cache/zypp/packages/repo-oss/x86_64/zypper-1.14.8-1.1.x86_64.rpm

This means you have used some updater applet or ‘zypper up’ before. No other way this can have happened.

First. Been using TW for some time now. I don’t use applet to upgrade packets. This is my media box running Kodi for my TV and I don’t want it to update itself.

Second. Yes and No. At least not since my upgrade to TW.

According to my history my last “zypper up” was at:

597  2017-08-28 16:39:49 zypper up

That was before i upgraded this machine to TW.

My next step was.

610  2017-08-28 17:57:49 zypper dup

Don’t remember which opensuse version it was. Think it might have been Leap 42.2.

So. Your wrong. In my case, there is a way it could happen. And in my case the solution was to bootstrap zypper. And after that zypper dup. Problem solved. I admit it was a long time between the dups. Almost a year and a day, which shouldn’t, in theory be a problem.

Now. Care to explain in detail how this can’t happen?